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The  Mission  of  AGARD 


According  to  its  Charter,  the  mission  of  AGARD  is  to  bring  together  the  leading  personalities  of  the  NATO  nations  in  the  fields 
of  science  and  technology  relating  to  aerospace  for  the  following  purposes: 

—  Recommending  effective  ways  for  the  member  nations  to  use  their  research  and  development  capabilities  for  the 
common  benefit  of  the  NATO  community; 

—  Providing  scientific  and  technical  advice  and  assistance  to  the  Military  Committee  in  the  field  of  aerospace  research  and 
development  (with  particular  regard  to  its  military  application); 
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—  Improving  the  co-operation  among  member  nations  in  aerospace  research  and  development; 

—  Exchange  of  scientific  and  technical  information; 

—  Providing  assistance  to  member  nations  for  the  purpose  of  increasing  their  scientific  and  technical  potential  . 

—  Rendering  scientific  and  technical  assistance,  as  requested,  to  other  NATO  bodies  and  to  member  nations  in  connection 
with  research  and  development  problems  in  the  aerospace  field. 

The  highest  authority  within  AGARD  is  the  National  Delegates  Board  consisting  of  officially  appr^inted  senior  representatives 
from  each  member  nation.  The  mission  of  AGARD  is  carried  out  through  the  Panels  which  are  composed  of  experts  appointed 
by  the  National  Delegates,  the  Consultant  and  Exchange  Programme  and  the  Aerospace  Applications  Studies  Programme.  The 
results  of  AGARD  work  are  reported  to  the  member  nations  and  the  NATO  Authorities  through  the  AGARD  series  of 
publications  of  which  this  is  one. 
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During  the  past  decade,  nuuiy  avionics  functions  which  have  traditionaUy  been  accomplished  with  analogue  hardware 
technology  are  now  being  accomplished  by  software  residing  in  digital  computers.  Indeed,  it  is  clear  that  in  future  avionics 
systems,  most  of  the  functionality  of  an  avionics  system  will  reside  in  software.  In  order  to  design,  test  and  maintain  this  software, 
software  development/support  environments  will  be  extensively  used.  The  significance  of  this  transition  to  software  is 
manifested  in  the  fact  that  SO  percent  or  mote  of  the  cost  of  acquiring  and  maintaining  advanced  weapons  systems  is  directly 
related  to  software  considerations.  It  is  also  significant  that  this  dependence  on  software  provides  an  unprecedented  flexibility  to 
quickly  adapt  avionics  systems  to  changing  threat  and  mission  requirements.  Because  of  the  crucial  importance  of  software  to 
military  weapons  systems,  all  NATO  countries  are  devoting  more  research  and  development  funds  to  explore  every  aspect  of 
software  science  and  practice. 

The  purpose  of  this  Symposium  was  to  bring  together  military  aerospace  software  experts  from  all  NATO  countries  to  share  the 
results  of  their  software  research  and  development  and  virtually  every  aspect  of  software  was  considered. 
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Au  coufs  de  la  demiere  dMennie,  bon  nombre  de  fonctions  avioniques  qui  etaient  traditionnellemem  realist  par  des  materiels 
bisant  appel  a  des  technologies  analogiques  le  sont  maintenant  par  des  logiciels  integrn  a  des  ordinateurs  numeriques.  En  effet. 
il  est  Clair  que  dans  les  systemes  avioniques  futurs  la  plupart  des  fonctionalitK  de  ceux-ci  rnideront  dans  le  logiciel. 

Que  ce  soit  pour  la  conception,  les  tests  ou  la  maintenance  de  ce  logiciel,  un  tr^  large  appel  sera  fait  aux  environnements  de 
support/developpement  de  logiciel.  L'importance  de  cette  transition  vers  ie  It^ciel  est  attest^  par  le  fait  qu'au  moins  cinquante 
pour  cent  des  couts  d’acquisition  et  d'entretien  des  systemes  d'annes  avanc«  sont  directement  lies  a  des  consideratioas 
logicielles.  D  est  aussi  significatif  que  cet  assujettissement  apporte  une  flcxibilite  sans  precedent,  permettant  d'adapter 
rapidement  les  systemes  avionitgies  a  des  situations  de  menace  et  des  exigences  operationnelles  en  constante  evolution. 

Vii  l’importance  capitate  des  logiciels  pour  les  systemes  d'armes,  les  pays  membres  de  I’OTAN  attribuent  de  plus  en  plus  de 
ressources  R&D  a  I’examen  de  tous  les  aspects  de  la  science  et  de  la  pratique  du  logiciel. 

L'objet  du  symposium  etait  de  reunir  les  experts  en  logiciel  aerospatial  militaire  de  tous  les  pays  membres  de  I’OTAN.  afin  de 
permettre  une  mise  en  cotnmun  des  r^ultats  des  activity  de  R&D  dans  ce  domaine,  et  virtuellement  tous  les  aspects  de  la 
conception  des  logiciels  etaient  abordm. 
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INTRODUCTION 

The  6Sth  Symposium  of  the  AGARD  Avionics  Panel 
was  held  in  Paris,  France,  on  May  10  to  May  13  1993. 
The  subject  of  this  symposium  was  'Aerospace  Software 
Engineering  for  Advanced  System  Architectures'.  The 
programme  Chairmen  were  Mr  John  J.  Bart,  of  Rome 
Laboratories,  and  Or  Charles  H.  Krueger,  of  Wright 
Laboratories,  both  from  the  U.S.A. 


THEME  OF  THE  SYMPOSIUM 

The  theme  of  the  symposium  was  quite  broad  :  to  bring 
together  software  experts  from  all  NATO  countries  to 
share  the  results  of  their  research  and  development  in 
every  aspects  of  software  engineering. 

This  choice  of  theme  for  the  symposium  was 
argumented  through  the  obviously  crucial  importance 
taken  by  software  in  advanced  weapon  systems,  since 
most  of  the  functionality  of  future  systems  resides  in  it, 
providing  in  addition  an  unprecendented  level  of 
flexibility.  The  common  consciousness  of  that  has  led  all 
countries  to  intensify  research  and  developement  in  that 
field. 

But  in  facL  another  underlying  reason  for  such  a  theme 
is  what  has  been  called  (rightly)  by  some  sprakers  'the 
software  crisis'.  In  some  older  times,  software  may  have 
been  considered  as  an  easy  way  to  implement  some 
functions  in  systems.  The  advantages  of  doing  so  were 
claimed  to  be  doability  and  flexibility  :  there  were  no 
envisionned  limitation  to  the  capability  of  software  to 
realize  a  function  and  to  be  modifled  as  wished, 
considering  that  the  size  of  the  functions  that  were 
imfdemented  through  software  was  limited. 

Since  that  time,  people  have  discovoed  that  software 
engineering  is  a  techrology  and  as  such,  has  limitations 
inherent  in  the  stale  of  its  art.  But  these  limitations  are 
not  palpable,  not  precise.  They  are  not,  as  for  semi¬ 


conductor  technologies,  related  to  physical  features  of  a 
given  stare  of  the  art.  Tbey  are  not  tied  to  a  known  and 
measurable  parameter,  such  as  the  complexity  of  a 
specified  algorithm  or  more  broadly  of  a  software 
individual  module.  In  fact,  that  complexity  is  much  less 
a  driver  than  the  size  of  the  whole  software  system,  in 
relation  with  the  level  of  reliability  (or  safety,  or  quality 
...)  one  wants  it  to  reach. 

The  fact  that  the  limits  are  not  quantifiable  may  lead  to 
forget  that  they  exist :  This  can  explain  the  problems  that 
have  been  encountered  for  many  airborne  systems.  This 
mr  also  explain  the  figures  given  by  one  of  the 
Speakers,  Mr  Bergey  from  the  NAWC  (US),  that 
perfectly  demonstrated  what  is  indeed  "the  software 
crisis'  :  an  anrerican  study  has  come  to  the  results  that 
amongst  a  large  number  of  software  systems,  only  5% 
were  delivered  and  utilized  without  change  or  with 
minor  changes. 

In  that  situation,  the  theme  of  the  symposium  suggests 
that  the  'technology  of  .software”  includes  all  steps  of 
work  that  participate  to  a  software  product,  from  the  first 
specification  from  the  user  to  the  final  validation  / 
qualification  testing.  This  has  been  confirmed  by  many 
speakers. 


GENERAL  DESCRIPTION 

The  symposium  consisted  of  6  sessions.  The  first  four 
were  dedicated  to  the  typical  steps  of  software 
engineering  (according  to  a  waterfall  or  a  "V"  model), 
i.e.  specifleations,  design,  realization,  validation  and 
testing.  Session  5  was  on  software  management  and 
session  6  on  software  environments.  37  papers  were  to 
be  presented,  amongst  which  3  have  been  cancelled 
(without  any  notice). 

In  his  welcome  address,  fngdnieur  Gdndral  Vrolyk,  of 
STTE  (FR).  has  clearly  introduced  the  challenge  of 
software  engineering  :  software  has  to  be  considered 
relatively  to  its  whole  life  cycle,  including  the 
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mainieaance,  in  enter  to  obtain  a  "total  quality".  This 
means  rigorous  methods  for  the  entire  life  cycle, 
supported  by  a  variety  of  adapted  tools.  Before  trying  to 
realize  and  validate  a  software  product,  one  must 
validate  the  methods  and  processes. 

Dr  W.  Royce,  of  TRW  (US),  presented  then  an 
outstanding  keynote  address.  Dr  Royce'  explanation  for 
the  software  crisis  is  that  the  methixlologies  are  based  on 
a  requirement- first  approach.  Due  to  many  reasons,  the 
requirements  are  never  frozen.  The  inherent  (and 
theoretical)  flexibility  of  software  eases  changes 
happening  very  often.  Now  there  is  a  point,  when  this 
happens  loo  often,  where  it  defeats  the  theoretical  ability 
of  software  engineering  to  tolerate  the  modifications. 
Once  again,  in  that  process,  the  technological  limits  are 
bteaken.  Dr  Royce  (hen  proposes  a  brand  new  approach: 
architecture  first,  just-in-time-requirements.  This  would 
be  the  way  for  the  future  in  order  to  really  (re-)  establish 
a  high  degree  of  flexibility,  without  having  unacceptable 
consequences  on  cost,  reliability,  etc. 

With  that  very  accurate  presentation,  the  symposium 
was  really  launched  with  a  view  to  a  future  where  (he 
"crisis"  has  to  be  overcome,  tlmtugh  an  evolution  of  (he 
software  technology  in  order  to  ,jush  the  limits  away. 


TFX'HNICAL  EVALUATION 

Session  1  -  Softwan:  specifications 

Paper  I,  by  Mr  Chanel,  was  rather  on  methodology  than 
on  specifications.  The  main  lesson  was  that  when 
products  evolve  (here,  the  Airbus  aircraft  family),  the 
increasing  complexity  and  volume  of  .software  can  be 
matched  by  adapting  from  one  programme  to  the  next 
one  a  sound  methodology  and  powerfull  tools.  The 
speaker  did  not  see  a  limitation  to  that  process.  It  should 
also  be  noted  that  complexity  of  the  software  for  that 
type  of  aircraft  is  lowered  by  the  increasing  complexity 
of  the  hardware  architecture  (number  of  black  boxes  :uid 
thereoff,  of  connections) :  the  size  of  each  software  unit 
remains  reasonable.  Another  levson  was  the  necessity  for 
the  many  cooperants  to  share  a  same  "tool  architecture", 
and  not  only  a  software  architecture. 

Paper  2,  by  Mr  Paquot,  described  a  method  and  tools  for 
mcxlelling,  simulating  and  prototyping  executable 
software  specifications.  The  product  (rotorcraft  flight 
control  system),  method  and  tools  are  quite  specific.  The 
paper  shows  that  such  method  and  tools  now  exist  and 
may  work,  although  they  have  not  been  applied  to  a  real 
project.  Unreadable  transparents  made  the  presentation 
difficult  to  follow... 

Paper  3.  by  Mr  Borden,  was  an  interesting  presentation 
on  (he  difficult  problem  of  decision  making  processes. 
Here,  the  limitation  are  not  related  to  the  software  itself, 
but  rather  to  the  hardware  that  may  not  be  able  to  run  the 
software.  In  such  a  case,  where  the  limits  are  known  and 
measurable,  a  strategy  can  be  defined  and  implemented 


in  order  to  obtain  a  product  wich  is  not  the  best  one 
possible,  but  which  meets  the  es.sen(ial  part  of  the  need 
(it  is  "sub-optimal")  and  is  above  all  executable. 

Paper  4.  by  Mr  Cagnace,  tackled  the  problem  of  airbonie 
knowledge  based  svstems.  It  showed  that  with  new  tools 
(particularly  "XIA  ,  refercd  to  as  a  real  tecnological 
break-through),  the  expert  systems  can  now  be 
developped  with  the  same  kind  of  methodologies  ("V" 
model)  as  other  software  systems.  E-^xpert  modules  can 
be  developped  separately  and  then  "integrated"  m  the 
system  together  with  classical  software  components 
(same  philosophy  as  in  keynote  address,  the  framework 
being  the  inference  engine).  I'his  was  an  encouraging 
paper,  which  let  foresee  as  possible  real  knowledge 
basea  applications  on  hoard  future  aircraft,  although 
some  problems  still  need  to  he  .solved  (particularly,  the 
hardware  performances). 

In  paper  5,  Mr  Beurrier  described  tools  allowing  to 
develop  a  potentially  "zero  fault"  stsftware  for  ftight  by 
wire  system.  The  two  solutions,  a  unique  software 
versus  sevcrall  versions  in  order  to  obtain  the  safety 
needed,  have  not  been  compared  in  terms  of  elTiciency, 
costs,  etc. 

Session  2  -  Software  Itesign 

A  large  proportion  of  the  papers  presented  during  this 
session  dealt  with  the  Object  Oriented  Design.  This 
topic  has  in  fact  proven  to  be  controversial 

Mr  Occelli  (paper  6)  compared  Object  Oriented  Design 
and  Functional  Otienicd  Design,  llis  conclusion  were 
that  OOD  was  not  I'lll-  solution  to  the  software  crisis, 
and  that  FOD  was  stronger  for  retil  time  and  safely 
critical  products.  A  question  was  raised,  wether  OOD 
and  Ada  arc  compatible. 

Mr  Micoin  (paper  7)  described  the  advantages  of  a 
particular  (X)D  melhtxl  :  HOOD.  He  staled.  ha.sed  on 
real  programme  experience,  that  the  pair  "HOOD-Ada" 
is  workable  and  cfricieni,  but  has  some  lacks  for  real¬ 
time  ai^licaiions.  He  contradicted  thus  to  some  extent 
the  former  pre.sentation. 

Paper  8.  by  Mr  Diemunsch,  described  the  use  of  (K)D 
for  a  very  .specific  project.  With  this  method,  the  ('++ 
language  has  been  used.  is  recognized  to  be  well 
adapted  to  OOD  methods.  Use  of  neuronal  networks  is 
to  be  noted. 

The  HCX)D  method  was  also  the  basis  of  work  related  in 
papers  9  (by  Mr  Mala)  and  10  (by  Mr  litcan).  Paper  9 
(quite  complete)  presented  the  adv.nuages  and 
drawbacks  of  ll(X)D  :  although  it  is  recognized  that  it 
has  weaknesses  for  real-time  performances  and  analysis. 
Mr  Mala  would  recommend  using  HOOD,  ('ontrarily  to 
paper  7,  he  stated  the  existence  of  a  stuctural  gap 
between  the  HOOD  design  and  Ada  code  for  some 
applications.  Paper  10,  however,  did  not  raise  this 
problem.  In  answering  a  question,  the  author  said  that 
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his  experience  was  that  HOOD  could  be  efOcient  for 
real-time. 

But  there  were  also  oilrer  areas  treated.  Paper  8a,  by  Mr 
Hameetinan,  described  the  experience  of  using  a  set  of 
current  off-the-shelf  tools  for  a  "small"  product  (9000 
lines  of  "C"  code)  which  needed  a  high  degree  of 
reliability  (satellire).  Advantages  and  drawbacks  of  the 
tools  were  discuused.  This  set  of  tools  was  deemed  as 
adapted  to  a  small  team  only. 

Paper  1 1.  by  Mr  Bose,  discussed  the  use  of  the  f.DS 
method,  which  is  a  CCITT  standard,  based  on  automats. 
The  main  advantage  is  the  reduction  of  the  testing  effort. 
Here  again,  problems  with  real-time  (communications 
between  tasks)  were  evoked. 

Paper  12.  by  Mr  Hoebel,  described  a  large  scale 
programme  of  Rome  Lab  in  tlie  area  of  knowledge  based 
engineering.  Of  most  general  interest  is  the  effort  on  a 
KB  software  assistance  toolset,  that  intend  to  assist  in 
ctKadinating  all  software  activities  in  a  project  and 
provide  guidance  to  users  in  elaborating  executable 
specifications. 

The  two  first  sessions  have  showed  that  a  number  of 
methods  and  supporting  tools  may  be  used  succesfully 
(but  one  could  question  wether  this  represents  the  real 
world  :  the  papers  dicussed  only  succes.sful  projects...). 
A  larger  approach  to  software  projects  is  needed, 
including  the  specification  phase  which  is  critical.  No 
method  seems  to  overcome  the  others  in  all  areas.  The 
future  seems  however  to  depend  on  very  sophisticated 
tools,  but  will  it  be  sufficient? 

Session  3  -  Programming  practices  and  techniques 

Paper  1 3.  by  Miss  Noganno.  presented  a  method  used 
for  prediciting  an  analysing  coding  errors  in  safety 
critical  software.  The  method  has  not  been  implemented 
(XI  large  projects. 

Paper  14.  by  Mrs  Kean,  described  the  Rome  Lab's 
programme  in  software  engineering  technologies.  Here 
appear  some  concepts  that  may  be  widely  spread  in  the 
future,  such  as  frameworks,  re-usable  software 
components,  functional  prototyping.  Industry  is  closely 
involved  in  these  activities,  which  is  certainly  a 
necessity  in  order  to  obtain  usable  tools,  but  is  not 
sufficient  for  making  these  tools  become  recognized 
standards.  A  recognized  standard  necessitates  that  a 
large  proportion  of  the  industry  uses  it  We  must  keep  in 
mind  that  the  defense  industry  is  (Xily  a  part  of  it,  not 
necessarily  large  enough  to  ensure  the  success  of  a 
standardizaticxi  process.  This  problem  of  standardization 
has  been  raised  during  the  question  .session. 

Paper  15 :  cancelled 

In  paper  16,  Mr  Benjamin  presented  the  Common  Ada 
Run-Time  System  of  the  USAF.  This  interesting  paper 
raises  again  the  question  of  standardizatiixi,  at  mother 
level.  So  many  countries,  services  and  companies 


develop  their  own  Ada  RTS  ;  how  can  we  ensure  re-use 
and  portability  without  a  certain  level  of 
standanlization?  Why  do'nt  these  questions  be  bandied 
at  adequate  intematicxial  levels?  This  does  not  seem  to 
be  a  concern  for  the  USAF,  since  CARTS  is  not 
intended  to  be  proposed  as  a  public  standard. 

Paper  17.  by  Mr  Richard-Foy,  describes  a  RTS 
ad^ssing  a  subset  of  Ada  for  s^ety  critical  systems. 
This  raises  the  same  questicxi  as  above... 

In  paper  18.  Mr  Gauthier  ininxluced  aniXher  newly 
developped  operating  svstem.  that  can  be  applied  to  an 
Ada  RTS.  It  has  been  designed  to  solve  caching 
problems  encountered  in  real-time  multiprocessor 
systems.  This  paper  was  technically  interesting  and 
accurate,  but  somewhat  ccxitroversed  in  its  hypotheses 
during  the  discussion.  This  shows  again  that  one  specific 
problem  may  have  a  number  of  solution. 

This  session  witnessed  the  large  number  of 
developmenis  and  studies  txi  going  cxi  ctxling,  although 
coding  is  generally  no  more  seen  as  the  most  acute 
problem  in  software  engineering. 

Session  4  -  Software  validation  and  testing 

Testing  is  clearly  a  major  aspect  of  software 
engineering.  As  stated  by  txie  speaker,  it  represents  25  to 
50  %  of  the  global  effort,  the  major  problem  is  (and  has 
been  fot  as  long  a  time  as  software  engineering  exists) 
that  a  softv  je  system  cannot  be  tested  thoroughly,  at 
least  at  the  current  state  of  the  art.  The  questions  are  then 
bow  to  do  the  right  choices  and  how  far  to  go? 

Paper  19.  by  Mr  Di  (liandomenico.  discussed  the 
developmeni  of  a  data  acquisition  system  for  integratitm 
testing  purposes  and  the  problems  encountered  Ihe  fast 
evoluticxi  of  indusuial  standards  and  liai  dware  were  nrx 
the  least  (xies  Is  the  solutkxi  in  more  "open”  systems? 

Paper  20.  by  Mrs  Di  (’arlo,  described  a  company- 
developped  test  tcxilsct.  The  tcxils  developped  allowed  a 
213%  reducticxi  in  testing  effort.  Ilie  basic  finding  was 
that  the  ccxnmercial  off-the-shelf  tcxils  do  not  provide 
for  thorough  solutions  for  the  .software  life-cycle  in 
aeronautics.  Will  the  aerospace  indusuy  be  able  to 
influence  the  market,  or  will  they  be  continuously 
obliged  to  develop  the  tools  and  methods  they  need?  The 
paper  was  rightly  ctxisidered  as  "frightening”  by  the 
sessi(xi  chairman. 

Paper  21.  by  Mr  Stephenson,  was  a  very  comprebensivi. 
presentation  of  all  the  stages  of  testing  a  complex 
avionics  system.  Stale  of  the  art  proces-ses  and  uxtls  are 
described.  Instructive.  Testing  the  complete  system,  at 
late  stages,  is  really  a  major  challenge,  and  includes  the 
fine  measurements  (propagation  delays)  necessary  to 
finalize  the  weaptxi  system. 

In  the  (xxitinuity  of  paper  21,  Mr  Satterthwaitc  described 
then  the  different  prextesses  involved  in  testing  airborne 
software  programs.  He  establi.shed  that  thorough  testing 
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is  impossible  and  thus,  testing  requires  comprehensive 
tools.  Testing  must  be  done  against  normal  and 
aboonnal  situations. 

Paper  23.  by  Mr  Ward,  presented  a  method  for 
validating  safety  critical  software.  It  was  based  on 
experience  on  a  real  project.  The  use  of  a  formal 
s^'''*cification  language  (Z),  together  with  the  classical 
static  and  dynamic  testings,  allowed  to  obtain  a  safe 
product  (but  not  fault  free).  To  be  noted  that  the 
software  was  "smaH"  (500  LtX").  It  was  affirmed  that 
using  Ada  tasking  with  its  full  features  is  quite 
impossible  in  such  a  system. 

Paper  24  was  cancelled. 

Paper  25.  by  Mrs  Gordon,  was  a  hymn  to  motiving  the 
teams  in  charge  of  testing  and  v^idaling  a  software 
system  (applied  to  the  F22)  ;  discipline  and  Iuh^w  bow 
are  neces.sary,  but  state  of  mind  and  organization  arc  loo. 

The  le.s.sons  learned  during  this  session  were  numerous. 
Older  techniques  and  toids  are  now  ouipassed  and 
unefficient.  Perspectives  for  testing  is  in  improving  the 
efficiency,  probably  not  in  reducing  the  costs.  There  is 
no  response  today  to  the  problem  of  saieiy  critical 
software  texcepi  for  small  ones).  Testing  must  be 
envisaged  in  the  earlier  stages  of  a  programme.  And  so 
on  :  everyone  can  find  in  that  very  rich  session  his 
proper  lessons. 

Session  5  -  Software  management 
Paper  26 ;  cancelled. 

Paper  27.  by  Mr  Naim,  proposes  a  new  ftoject  Support 
Environment  designed  by  the  DRA  (UK)  to  make  the 
software  svstems  independent  from  the  developpers  and 
from  spec.."ic  tools  or  environments,  through  its  entire 
life-cycle.  This  environment,  oriented  towards  the 
engineering  description.  Ls  proposed  for  standardization, 
rather  than  the  technology  oriented  standards  such  as 
PCTE  or  CAIS.  It  has  been  tested  by  transcription  of  an 
existing  programme,  but  not  yet  used  on  a  real  project. 

Paper  28,  by  Mr  Brammer,  proposes  to  extend  the 
software  engineering  maturity  model,  developped  by  the 
Software  Engineering  Institute,  to  build  a  system 
engineering  maturity  model.  Modifications  should  be 
minor.  The  framework  for  this  model  is  not  complete. 

Paper  29.  by  Mr  Sandrelli,  dealt  with  quality 
improvement  through  classical  hierarchical  breakdown 
structure,  configuration  management  and 
documentation.  Project  management  is  improved  by 
timely  and  standardized  information  diffusion,  through  a 
database. 

Paper  29a,  by  Mr  Bergey,  presented  a  product  oriented 
approa  ch  to  the  software  project  management  (based  on 
the  US  Navy  SPORE  model).  The  main  problems  the 
author  sees  in  software  engineering  are  quality  and 
ability  to  be  modified.  But  the  primary  driver  is 


specification  :  if  they  are  bad.  the  product  will  be  bad 
This  is  the  GIGO  process  (Garbage  In.  Garbage  Oui>.  He 
stated  that  the  quality  payoff  is  cost  saving.  SK)KE 
allows  to  obtain  full  visibility  of  the  product,  at  each 
stage  of  the  development.  SPORIi,  in  its  last  version,  has 
not  yet  been  used  on  a  real  project. 

This  session  has  demonstrated  the  awareness  of  the 
imporuance  of  management.  Solutions  really  <q>plied 
are  'classical"  and  for  the  future,  many  concepts  are 
studied.  Type  of  management  is  in  fact  intrinsically  tied 
to  the  history  and  culture  of  the  system  builder.  Will  the 
customers  be  able  to  change  that  and  to  impose  their 
vision? 

Session  6  -  Software  environments 

Lack  of  adequate  tools  has  been  considered  a  major 
problem  some  years  ago.  This  is  no  more  the  case  today. 
But  linking  together  the  different  tools  supporting  the 
different  activities  of  software  engineering  is  still  one. 

Paper  29b,  by  Mr  Goodwin,  illustrated  this.  After  a 
presentation  of  the  KuroFighter  Software  Development 
Environment,  which  is  based  on  a  framework.  Mr 
Goodwin  had  a  look  to  the  future.  According  to  him. 
based  on  the  EF  experience,  many  p.oblems  are 
unsolved-  Software  engineering  is  a  part  of  a  wider 
activity  (system).  Re-use,  prototyping,  automatic  code 
generation  are  to  be  developped.  Totals  reamin  a 
nece.ssity  and  have  to  become  stable,  in  order  to  avoid 
large  modification  in  the  life-c.  cle  (corjnercial  uxils  are 
highly  volatile,  due  to  the  market).  Multinational 
cooperation  necessitates  integrated,  common  kxils  and 
this  is  not  recognized  enough.  Using  different  meihixls 
make  errors  possible  at  each  interface  and  should  not  be 
envi.saged.  although  not  impossible.  This  was  a 
somewhat  pes.simi.stic  (but  realistic)  paper. 

Paper  30.  by  .Mr  Fraboul,  was  more  optimistic.  It 
described  quite  clearly  a  tcxil  allowing  to  programming 
fault  tolerant  applications  distributed  on  parallel  harware 
architecture.  l.aboratory  results  were  excellent.  This  is 
crucial  for  the  future,  because  avionics  architectures  will 
be  more  and  more  parallelized  and  disuibuted  (see  Pave 
Pace,  ICNIA.  ASAAC,.  > 

Paper  31.  by  Mr  Cheraizu,  decribed  the  AIMS  Eureka 
project.  This  is  an  indusuial  project  aimed  at  improving 
methods  in  a  "pragmatic"  approach.  One  of  the  areas 
concerned  is  the  collaborative  work  in  mu.d-partners 
programme  :  this  shows  that  progress  are  needed  in  that 
field...  AIMS  is  in  its  demonstration  phase  (on  real  part 
of  various  intemaiional  programmes).  Up  to  now.  result^ 
claimed  are  mainly  a  more  common  understanding  of 
the  developments  between  the  3  companies.  Significant 
results  are  foreseen,  after  an  integration  phase. 

Paper  31a.  by  Mr  Corbin,  described  an  environment 
dedicated  to  distributed  systems  with  low  bandwith 
communications,  such  as  missions  (mulli-)simulaiors. 
Ada  lacks  in  areas  of  dynamic  binding  and  inheritance 
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can  be  overcome.  So  Ada  weaknesses  are  noi  a 
(voblem? 

In  paper  32.  Mr  Coglianese  presented  a  DARPA 
appraocb  to  future  software  engineering.  It  consists  in 
separating  an  avionics  system  in  different  domains  and 
allowing  to  specify  the  system  in  domain-specific 
languages,  in  otder  to  obtain  and  exploit  re-usability. 

Paper  33,  by  Mr  Piieie,  described  the  Entreprise-2  open 
Cnimework.  Entreprise-2  features  generic  capacities  for 
managing  a  software  project,  including  a  data  base  for 
management  of  re-usable  components,  and  is  able  to 
integrate  or  to  lodge  specific  tools  for  supporting  the 
activities  during  the  whole  development.  This  is 
probably  the  kind  of  existing  framewoA  that  should  be 
advatageously  standardized.  This  project  reveals  a  new 
governmental  approach  in  the  area  of  software  tools  ;  to 
develop  them  and  to  encourage  the  contractor  to 
commercialize  them.  Specific  tools  for  the  defense  are 
expensive  to  maintain  and  upgrade,  and  defense  budgets 
can  no  more  afford  that. 

Session  6  was  well  balanced  between  actual 
environments  and  future  ones.  In  some  cases,  future 
seems  to  be  a ...  long  term  one. 


General  comments 

Generally  speaking,  the  symposium  has  met  the 
objective  to  give  an  overall  view  of  the  research  and 
developments  in  software  engineering  within  NATO  and 
to  share  the  results.  It  was  well  balanced  between  slate 
of  the  an  experience  in  elaborating  software  products 
and  developments  for  future  programmes.  In  general,  the 
impression  given  was  that  papers  on  present  projects 
showed  a  lot  of  questions  to  be  solved  and  papers  on 
future  projects  did  not  anticipate  any,  which  can  be 
considered  as  optimistic. 

AVP  does  not  provide  the  panicipants  for  evaluation 
forms,  in  order  for  them  to  give  their  view  on  the 
relevance  of  the  papers.  Personally,  to  a  quite  severe 
scaling,  I  rated  15  papers  as  excellent  or  very  good  (near 
50%,  which  is  very  good  as  far  as  I  am  concerned).  10  as 
good,  7  as  satisfactory  and  only  2  as  poor  or  irrelevant. 

The  state  of  the  art  was  very  well  described,  with 
accurate  highlights  on  the  advances  and  the  remaining 
problems.  Globally,  the  papers  presented  a  situation 
were  the  problems  related  to  actual  software  projects  are 
or  can  be  solved,  which  is  encouraging.  But  in  an  other 
hand,  the  situation  is  also  worrying.  Some  papers 
contained  figures  of  results  obtained  in  terms  of 
efficiency  or  productivity.  These  figures  were  between 
20  an  50%  after  consequent  developments.  What  in  that 
case  will  be  the  efforts  needed  in  order  to  cope  with  an 
order  of  magnitude  of  growth  for  future  projects,  with 
exponenliaily  increasing  complexity? 

Developments  for  future  programmes  were  necessarily 
tackled  in  terms  of  aims  and  objectives,  since  results  are 
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to  come.  These  objectives  were  individually  pertinent, 
but  they  revealed  different  directions  of  effort  so  it 
cannot  be  ensured  that  the  sum  of  individual  results,  if 
the  objectives  are  met,  will  enable  resolution  of  all 
problems,  because  of  bad  compatibility  between  them. 
This  is  a  traditional  problem  in  that  Held  :  software 
developpers  are  led  to  make  choices  in  terms  of  methods 
and  tools,  and  every  choice  has  its  adavniages  and 
drawbacks.  This  does  not  seem  to  change  in  the  near 
future. 

In  addition,  there  were  no  paper  (but  one,  n°  30)  given 
by  university  (or  university-like)  researcher.  Although  it 
can  be  recognized  that  real  experience  is  a  basis  for 
orienting  rese^h  and  developments,  many  "good"  ideas 
were  bora  in  the  universities.  The  links  with  these  bodies 
should  be  kept  alive! 

Ilie  discussions  allowed  alter  the  presentation  of  the 
papers  were  extremely  pertinent  and  interesting.  In  fact, 
much  of  the  very  problems  of  software  engineering  were 
tackled  during  the  di.scussions.  For  instance,  re-use  was 
a  topic  well  and  usefully  adressed  in  questions,  and  also 
the  need  for  methods  and  tools  for  formal  proof  of  the 
softw^  and  for  tool  standardization. 

If  1  had  to  find  a  cause  for  criticism.  I  would  point  out 
that  specific  problems  related  to  future  avionics 
architectures,  which  are  much  more  integrated,  although 
modular,  than  now,  have  not  been  considered  enough. 
Indeed,  these  problems  (distributed  architectures, 
dynamic  conFiguration  and  automatic  reconFiguration. 
etc)  will  also  be  critical  for  the  future  airborne  software 
systems.  If  this  point  has  been  taken  inU)  account  by  the 
Keynote  Speaker,  it  was  not  the  general  ca.se. 


RECOMMENDATIONS 

In  this  section,  the  aim  is  no  more  to  evaluate  the 
symposium,  but  to  draw  the  lessons  on  the  problematics 
of  software  engineering,  as  described  during  the 
symposium  and  with  the  assumption  that  the  sum  of  the 
papers  give  an  exact  perspective  of  the  state  of  the  art. 

The  general  impression  given  is  that  "the"  solution  to  the 
software  crisis  is  not  for  the  near  future.  Individual 
solutions  to  ^ciftc  problems  allow  advances  of  tens  of 
percent  (when  and  where  measured)  while  the 
complexity  and  size  of  future  airborne  software  systems 
are  anticipated  to  increase  by  one  or  more  order  of 
magnitude. 

It  appeared  often  in  the  papers  that  the  problems 
encountered  were  linked  to  the  hardware  architecture 
taken  into  account,  and  furthermore  that  new 
architectures  (at  system,  sub-system  or  pnxxssor  level) 
could  make  these  problems  obsolete.  Probably  is  it 
symptomatic  of  one  of  the  causes  of  the  software  crisis  : 
software  is  thought  in  close  relation  with  existing 
hardware  architectures  and  it  lacks  the  necessary 
hindsight  in  order  to  anticipate  on  the  future.  This  may 
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in  part  explain  that  software  technology  is  in  a  constant  improving  methods  and  tools  in  a  narrower  field,  which 

manner  S  to  10  years  behind  the  hardware.  will  make  them  less  expensive  and  mure  efficient.  It  is 

thus  recommended  first  to  establish  the  adequate  levels 
Software  engineering  is  still  today  envisaged  as  a  mean  of  standardization  for  methods  and  tools  in  software 

to  resolve  some  issues  (i.e.  it  is  a  way  to  realize  some  engineering  and  second  to  select  or  develop  the  related 

fuiKtions  on  plaifonns)  much  more  than  as  a  technology  standard  product,  with  the  aim  and  the  will  to  impose 

intrinsically  necessary  for  the  systems  and  which  must  their  use  in  all  NATO  real-time  programmes, 

thus  be  developped  as  a  peculiar  basis.  Avionics  systems 
are  considered  primarily  in  terms  of  hardware  capacity 
to  run  software.  Being  given  the  pre-eminence,  wincn  is 
recognized,  of  the  role  of  software  in  meeting  the 
requirements  and  the  fact  that  most  of  the  problems 
during  systems  developments  are  now  directly  or 
indirectly  related  to  (application)  software,  the  necessity 
to  think  future  systems  upfront  in  terms  of  available 
software  technology  must  be  assessed.  This  underlined 
clearly  the  Keynote  Address,  but  would  be,  as  from 
many  papers,  a  revolution  in  the  way  systems  are 
envisionn^  today. 

In  order  to  summarize,  there  seem  to  he  two  keys  for 
future  systems  :  costs  and  specifications. 

Costs  have  to  be  dra:  ,iiy  reduced,  and  to  that  end, 
c-omplexity  and  size  should  be  bandied  through  methods 
and  tools.  Of  particular  importance  are  re-use  and 
automatic  coding.  Re-use  has,  as  a  method,  not  yet  really 
started  to  be  exercized.  According  to  some  authors,  re¬ 
use  can  only  be  envisaged  at  lower  levels  of  software 
realization,  but  that  point  was  controversial.  But  in  faa, 
there  is  no  real  experience  on  large  sacle  re-use  today. 

Automatic  coding  is  also  restricted  to  some  narrow 
areas.  It  can  be  extended  to  automatic  testing,  although 
the  real  problem  of  software  formal  proof  is  far  from 
being  solvable.  Particular  emphasis  should  then  be  put 
on  these  topics. 

Specifications  are  another  heavy  problem,  because  in 
one  hand  they  are  never  as  accurate  as  needed  and  in  the 
other  band,  when  trying  to  obtain  executable 
specifications,  they  become  more  and  more  difficult  to 
elaborate.  Methods  and  tools  aimed  at  allowing  users  to 
elaborate  accurate  and  executable  specifications  should 
be  developped. 

Another  important  point  is  related  to  the  lack  of 
standardization,  both  for  methods  and  tools.  This  a 
severe  repercussions  on  portability  and  re-use,  but  also 
on  mainteiumce.  since  le  life-cycles  of  tools  are  much 
shorter  than  those  of  airborne  softwrae  products.  Apart 
from  Ada  as  language,  there  is  no  real  standard  within 
NATO.  One  reason  is  that  there  is  no  "perfect"  product 
to  be  standardized.  But,  in  one  hand,  there  will  never 
exist  "perfect"  methods  or  tools  (without  any  lack)  and, 
in  the  other  one.  one  don  not  need  that  a  product  be 
perfect  in  order  to  have  it  become  a  standard.  Ada  is  not 
a  perfect  language,  since  it  has  some  lacks  in  real-time 
(easy  to  surpass  today)  and  for  safety  critical  software, 
but  it  has  so  many  advantages  in  other  areas  that  it  is  a 
usefull  and  recognized  standard.  At  every  level,  given 
the  axiom  that  perfect  product  will  never  exist, 
standardization  is  far  better  than  nothing!  It  will  allow, 
in  particular,  to  concentrate  the  efforts  aiming  at 
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KEYNOTE  ADDRESS 


REQUIREMENTS  ENGINEERING  BASED 
ON  AUTOMATIC  PROGRAMMING 
OF  SOFTWARE  ARCHITECTURES 


Winston  Royce 
Systems  Integration  Group 
TRW 

One  Federal  Systems  Park  Drive 
Fairfax,  Virginia  2203J-4411,  U.S. 


o  The  Problem 
o  An  Emerging  Solution 
o  Some  Exploratory  Examples 


Software  development  methodologies  are 
generally  based  on  a  requirements-f irst 
approach. 


Business  considerations  require  at  some 
early  point  in  a  software  development 
that  the  requirements  ought  to  be  frozen. 

But  they  never  are. 


Why  aren't  software  requirements  frozen? 

The  acquisition  group  demands  mission- 
oriented  changes. 

The  user  group  demands  user-oriented 
changes . 

-  When  other  subsystem  elements  fail 
system  performance  is  preserved 
primarily  through  software  fixes. 

As  software  builders  incrementally  fix 
their  initial  design  weaknesses  they 
make  requirements  changes. 

All  of  the  foregoing  are  usually  unfore¬ 
seen  in  the  beginning. 


Software's  flexibility  inherently 
supports  change  particularly  with  respect 
to  requirements. 

Requirements  changes  -  particularly  those 
late  occurring  in  the  development  life 
cycle  -  are  troublesome  because  they 
defeat  a  business-like  approach. 

Software's  easy  flexibility  (combined 
with  its  logical  complexity)  also 
amplifies  its  intolerance  to  faults. 


A  major  problem  then  is  imposed  on 
software  developers. 

How  can  we  exploit  software's  flexibility 
for  prolonging  system  life  yet  quickly 
build  a  low  cost,  fault  tolerant  initial 
system? 


There  is  an  emerging  solution. 

I  would  term  it: 

Architecture  First  -  Requirements  Second 


What  does  "architecture-first"  mean? 

An  executing  architecture  is  built  very 
early  in  the  life  cycle  for  all  develop¬ 
ment  participants  to  use. 

Requirements  come  later. 


The  requirements  oriented  consequences  of 
an  early,  executing  software  architecture 
are: 

Performance  requirements  are  based  on 
executing  software  not  conjecture. 

-  User  requirements  are  not  attempted 
until  an  executing  software  infra¬ 
structure  exists  supporting  user 
operations . 

(Most)  requirements,  can  be  safely 
changed  at  anytime,  even  late  in  the 
life  cycle. 


Software's  easy  flexibility  is  simulta¬ 
neously  its  premier  strength.  Software's 
flexibility  is  the  best  mechanism  for 
adapting  a  system  to  its  unforeseen, 
long-term  future. 
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How  to  control  the  increase  in  the  complexity 
of  civil  aircraft  on-board  systems 

P.Chanet  V.CassIgneuI 
System  Workshop 
AEROSPATIALE 
A/DET/SY  MOIOi/K 
316,  route  de  Bayonne 
31060  TOULOUSE  Cedea  03 
FRANCE 


1  .  SUMMARY 

After  showing  how  the  complexity  of  digital  systems  is 
doubling  about  every  five  years,  and  evoking  the 
difficulties  caused  by  this  evolution,  a  methodological 
approach  is  described  called  the  "Systems  Development 
Workshop"  aiming  to  gain  mastery  of  this  evolution. 

Among  design,  production  and  validation  stages,  the 
importance  of  the  design  process  is  emphasised.  The  most 
acute  problems  of  system  development  are  generally 
described,  and  examples  are  given  of  the  power  and 
benefits  that  can  be  expected  from  computer  design  tools. 

System  architecture  design  and  functional  specirication  are 
expanded  somewhat,  to  show  what  benefits  can  be 
expected  from  an  integrated  approach.  Through  the  SAO 
example,  all  development  stages  are  evoked. 

A  rough  outline  of  the  necessary  capacities  fur  a  common 
work  enviroiunent  is  drawn. 

Finally,  it  is  noted  that  the  increasing  necessity  of 
international  cooperation  in  civil  aviation  consolidates 
the  proposed  approach. 

2  .  ONBOARD  SYSTEMS  :  INCREASING 

COMPLEXITY 

The  complexity  of  digital  systems  on  board  civil  aircraft  is 
constantly  increasing. 

Figure  I  shows  how.  for  AIRBUS  programs,  this 
complexity  of  on-board  systems  has  doubled  at  each 
program  ;  A3 10,  A320  and  A340.  That  is,  every  5  years, 
while  a  constant  reduction  in  the  volume  of  electronics 
required  to  perform  a  given  function  has  made  it  possible 
to  keep  the  overall  volume  of  the  onboard  electronics  more 
or  less  the  same,  mostly  thanks  to  VLSI  (Very  Large  Scale 
Integration)  technologies. 


Figure  1  -  Evolution  of  digital  system  complexity 


Examining  the  reasons  for  the  rapid  growth  in  the 
complexity  of  the  systems,  one  can  be  sure  that  this  will 
continue  for  the  next  10  years  : 

The  role  of  on-board  computers  is  steadily  increasing  ; 
their  impact  on  system  architecture  is  still  moderate. 
Software  developement  techniques  for  safe,  real-time 
systems  are  getting  mature,  together  with  multiplex  data 
links.  This  allows  for  a  certain  amount  of  independaiKe 
between  functions  and  their  supporting  harware.  The  trend 
is  towards  de-localization  of  the  functions  within 
homogeneous  hardware  ("modular  avionics"),  making  the 
overall  functional  architecture  all  the  more  complex  and 
difficult  to  regulate. 

Conversely,  computing  power  and  software  versatility 
make  new  functions  available  for  the  aircraft.  In  the  KOs. 
digital  systems  made  ’ny-by-wire"  controls  and  electronic 
instrument  panels  possible,  with  their  increased 
flexibility  and  safety  features.  In  the  '90s.  they  will  help 
control  the  structural  flexibility  phenomena  of  wide  body 
aircraft,  with  active  control  to  improve  passenger  comfort. 
In  addition,  one  must  foresee  the  development  of 
navigation  and  communications  systems  incorporating 
such  new  functions  as  GPS  (Global  Positioning  System)  or 
greatly  enhanced  ground/aircraft  dialog  through  digital 
links  :  ATM  (Air  Traffic  Management)  and  ADS 
(Automatic  Dependent  Surveillance).  Mastering  these 
additiormal  functions  is  of  course  a  great  commercial  asset 
for  an  aircraft  manufacturer. 

The  ever  increasing  level  of  interconnection  between 
systems  will  inflate  the  volume  of  information  exchanged. 
This  is  a  natural  development  mainly  linked  to  the 
automation  of  secondary  tasks,  allowing  the  pilot  to 
concentrate  on  flight  control. 

Last  but  not  least,  onboard  systems  are  getting  an  ever 
greater  influence  on  flight  safety,  thus  requiring  tight 
controls  of  design  and  manufacture  (design-for-safety,...). 


3  .  CAN  THE  DEVELOPMENT  OF  COMPLEX 
SYSTEMS  BE  MASTERED  7 

The  more  complex  a  system  is,  the  more  difficult  it  is  to 
keep  within  cost  and  schedule.  Can  the  development  of 
very  complex,  safety-constrained  systems  really  be 
mastered  7  The  Airbus  and  ATR  experiences  of  last  are 
proof  that  it  is.  even  in  the  context  of  international 
cooperation. 

What  are  the  main  problems  plaguing  the  development  of 
complex  systems  ?  Most  common  problems  are  ; 

cost  and  lime  to  get  each  function  work  ! 

technical  coordination,  and  associated  difficulties 
in  integrating  the  system 
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how  to  make  it  dependable  and  lo  certify  it  after  it 
is  developped  ? 

Let  us  develop  somewhat  on  these  problems. 

3.1.  the  InfanoHs  "Make-and-dcbug'* 
approach 

A  lot  of  experience  is  the  field  of  on-board  systems,  and 
not  only  in  aeronautics,  has  shown  how  costly  a  "design, 
make  and  debug"  approach  can  be.  Debugging  actions 
imply  numerous  and  late  design  changes.  The  later  the 
change,  the  higher  the  cost  and  schedule  penalty. 
Furthermore,  no  validation  action  is  possible  in  this 
approach  before  a  first  set  of  equipment  has  been  produced, 
at  full  cost. 

A  well-known  example,  is  the  Flight  Management  System 
(FMS),  the  debugging  of  which  required  several  thousand 
design  changes,  ending  up  with  a  certification  delay  of 
several  years  with  respect  to  the  original  schedule. 

Systems  with  intensive  interaction  with  man  are  the  most 
difflcult  to  tune,  regardless  of  their  intrinsic  complexity. 
Only  a  constant  dialog  with  the  future  users  (crews,  etc...) 
from  the  pre-projecl  phase  on  will  allow  for  a  satisfactory 
definition  of  these  systems. 

Our  aim  is  therefore  clear,  we  must : 

minimize  the  number  of  design  changes  needed, 

discover  them  and  embody  them  at  the  earliest 
possible  stage. 

How  can  we  get  out  of  the  habit  of  making-and-debugging 

7 

Quality  insurance  offers  a  set  of  solutions  :  design  critical 
reviews,  communication  and  updating  procedures  for 
overall  consistency,... 

The  mastery  of  accurate  models  of  physical  phenomenons 
(aerodynamics,  structural  stress,  electricity  and 
electromagnetics,  fluid  dynamics...),  of  complex  real-time 
simulation,  and  of  automatic  code  generation  open  another 
set  of  solutions  :  early  prototyping  and/or  simulation,  if 
possible  with  no  physical  equipments. 

The  chosen  approach  becomes  : 

whenever  possible,  substitute  early-stage  design  review  or 
simulation  to  the  more  costly  design-make  and  debug 
approach. 

We  will  give  examples  of  the  benefits  of  such  an  approach 
later  on. 

3.2.  Industrial  cooperation  &  technical 
coordination 

Airbus  or  ATR  programs  are  carried  out  in  international 
cooperation.  Design  offices  must  coordinate  on  a  common 
design,  with  the  help  of  a  very  light  coordination 
structure. 

The  sheer  volume  of  the  design  makes  such  a  coordination 
quite  difficult. 

For  instance,  the  length  of  the  electrical  wiring  installed 
on  an  aircraft  totals  180  km  ;  production  of  the  electrical 
drawing  set  and  its  management  is  a  formidable  task  indeed 
when  3  or  more  design  offices  conuibuu:  to  it  ! 


The  logical  definiiitm  of  interfaces  between  systems  is 
even  more  complex,  especially  when  several  versions  ate 
being  developped  simutaneously. 

Ensuring  the  consistency  between  all  teams  is  a  matter  of 
defining  a  common  design  reference,  of  configuration 
control  and  of  communicating  early  and  accurately  to  the 
right  people  all  changes  made  or  requested. 

•  Inltufuces  between  systems  : 

This  is  one  of  the  most  difficult  problems  to  master,  first 
because  of  the  very  large  number  of  data  and  information 
exchanges  which  exist  and  also  because  of  the 
asynchronous  operation  of  the  various  computas. 

To  address  the  interface  problem,  Aerospatiale  has  made  up 
a  data  bank  of  signals  exchanged  in  the  aircraft  in  order  to 
obtain  centralized  management.  The  resulting  functions 
are  : 

description  of  the  signals  exchanged, 
management  of  interfaces  between  equipment, 
consistency  check  on  these  exchanges. 

The  second  problem  concerns  the  "dynamic"  interface  of 
the  electric  signals  exchanged.  The  asynchronous 
operatimi  of  onboard  computers  can  generate  temporary 
disagreements,  which  are  often  troublesome  for  the  crews, 
especially  in  the  case  of  electrical  transients  and  on 
automatic  reinitialization  of  one  of  the  computers.  The 
large  number  of  equipment  manufacturers,  each  with  their 
own  interpretation  of  the  exchange  rules  (ARINC  429 
standard)  only  increases  the  difficulty.  Today,  this 
problem  is  dealt  with  by  a  consistency  check  on  all  the 
signals  exchanged  between  computers. 

By  addressing  this  problem  from  the  design  stage,  we 
know  how  to  reduce  the  number  of  spurious  indications 
and/or  unwanted  disconnections  of  the  onboard  systems. 

«  Definition  and  installation  of  electrical  wiring  : 

;  the  same  applies  to  the  routing  of  these  cables  which 
must  comply  with  stringent  segregation  and  insullation 
rules. 

To  deal  with  this  task,  we  have  developed  a  tool  called 
CIRCE  (Conception  Informatisde  et  Rationalisde  des 
Cablages  Electriques  ;  Rationalized  and  computerized 
design  of  electric  cables)  which  allows  ; 

wiring  diagrams  to  be  produced  in  CAD. 

the  list  of  cables  to  be  manufactured  to  be  extracted 
in  computer  file  form, 

these  cables  to  be  allocated  to  the  assemblies 
(harnesses)  and  to  their  subassemblies  (which 
correspond  to  manufacturing  operations), 

data  bank  management  of : 

•  standard  items, 

•  diagrams, 

•  cables, 

•  cable  terminations. 

the  routing  of  the  electric  cables  to  be  deBned  in 
3D  CAD. 

The  latter  function,  associated  with  automatic  calculation 
of  bundle  lengths  allows  the  requirements  of  the 


1-3 


Pioduclioii.  inspection  snd  Product  Support  departments  to 
be  met  from  the  design  stage. 

3.3.  Oepcndabtlit}  &  Certification 

Dependability  has  (at  least)  four  compoents  :  safety, 
reliability,  availability,  maintainability. 

Achieving  dependability. 

Unmastered,  the  search  for  dependability  is  a  close  variant 
of  the  "make-and-debug"  approach,  as  certification  and/or 
dependability  analysis,  at  the  end  of  a  program,  make  then 
a  sudden,  unexpected  demand  for  numerous  and  deep  design 
changes. 

Dependability  must  be  achieved  all  along  a  project.  It  is  a 
continuous  process  and  an  integral  part  of  the  design, 
manufacture,  validation  and  in-service  operation  stages. 

Without  attempting  to  sununarize  in  a  few  lines  all  the 
tasks  allowing  this  dependability  to  be  obtained,  we  can 
mention  the  most  significant  aspects. 

This  is  a  discipline  which  reflects  the  will  to  control  the 
technical,  human  or  environmental  hazards.  It  is  based, 
not  only  on  the  experience  acquired  (regulations, 
standards),  but  also  on  the  ability  to  prevent  risks  by 
predicting  them. 
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Figure  2  -  Domain  of  compliance  of  events  :  conse¬ 
quences  versus  probability 

During  Design 

The  prediction  of  functional  failures  and  the  assessment  of 
their  consequences  allows  : 

•  the  criticalities  of  the  functions  to  be  defmed, 

•  safety  objectives  to  be  allocated  to  the  functional 
failures  expected,  thus  to  functions  themselves, 
and  then  to  their  underlying  equipments. 

Dependability  is  then  used  as  a  basis  for  the  architectural 
design  of  the  systems,  and  for  quality  assurance,  by 
allocation  of  performance  objectives  to  the  items  in  a 
system  :  this  procedure  was  used  for  the  ftrst  time  on 
Concorde. 

The  prediction  of  external  aggressions  (lightning,  icing) 
or  specific  hazards  (engine  burst,  bird  strike)  makes  it 
possible  to  define  : 

•  the  installation  directives,  (segregation,...) 

•  design  precautions,  (shielding  of  cables  exposed  to 
lightning... ) 

•  circuit  protections  (guards  protecting  the  circuits 
against  running  fluids...) 

Validation  and  Demonstration 

Demonstration  of  dependability  is  often  a  matter  of 
putting  together  various  analysis  (i.e.  failure  mode 


analysis)  and  test  results,  in  a  somewhat  "bottom-up" 
approach,  for  comparison  to  dependability  objectives 
allocated  in  a  top-down  fashion. 

Quality  assurance  takes  all  its  importance  here,  by 
wananting  that  the  necessary  actions  are  taken  to  keep 
track  of  the  objectives  and  to  get  the  necessary  measures. 
It  is  often  enforced  through  regulation,  for  example,  for 
onboard  software,  stringent  quality  assurance  measures, 
based  on  the  RTCA  DO  178  document,  are  applied. 

Safety  analysis  provides  a  good  example  of  the 
demonstration  problem. 

Two  tools  are  available  and  widely  used  today  within  the 
scope  of  the  Airbus,  ATR  and  Hermes  programs  : 

The  first  tool  named  SARA  (Safety  And  Reliability 
Analysis)  is  dedicated  to  collection  and  synthesis  of  safely 
data  at  the  system-level. 

The  second  tool  named  DAISY  (Dependability  Aided 
SYnthesis)  allows  the  SARA-analyses  of  each  system  to  be 
linked,  ensures  their  coherence  and  deduces  the  global 
safety  level  of  the  aircraft. 

In-service  support  : 

Dependability  participates  in  maintaining  the  continued 
airworthiness  of  the  aircraft :  the  airworthiness  follow-up 
allows,  with  hindsight,  the  hypotheses  made  during  the 
design  phase  to  be  confirmed.  This  leads  to  a  typical 
problem  of  corporate  memory,  as  follow-up  data  keep 
trickling  back  during  the  20  to  25  years  of  an  aircraft-type 
lifespan. 

4  .  SYSTE,M,S  DEVELOPMENT  WORKSHOP 

Mastering  the  development  of  complex  systems  appears  to 
draw  on  4  main  capacities  : 

the  ability  to  simulate  or  review  specifications 
early. 

the  ability  to  communicate  and  to  ensure 
consisteiKy  all  along  the  development  between  all 
partners,  while  preserving  beneficial  independance 
(concurrent,  asynchronous  engineering). 

the  ability  to  assign  performance  objectives  (for 
instance  dependability  objectives)  to  all  items  and 
to  track  and  document  these  objectives  through 
multiple  versions  of  the  product  definition, 

the  ability  to  produce  updated  documentation  in 
pace  with  the  technical  work. 

This  can  only  be  achieved  with  a  rational  and 
methodological  approach  to  system-development  within  a 
organized  structure.  In  Aerospatiale,  this  structure  is  called 
the  Systems  Development  Workshop. 

4.1.  Definition 

"The  systems  workshop  is  the  coherent  set  of  methods  and 
tools  required  for  optimum  development  of  systems  within 
a  given  aircraft  program  context". 

As  we  do  not  start  from  scratches,  the  System  Workshop 
approach  must  be  an  integrative  approach,  bringing 
together  existing  tools  and  methods  into  a  common 
methodological  framework. 

It  must  observe  the  practical  industrial  organization,  and 
provide  means  of  communication  and  reference  data-bases 
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ill  accofdance  to  th«  actual  coordination  networks  and 
nmlM-vous. 

A  formal  expression  of  specification  will  be  highly 
regarded,  siiKe  it  give  all  4  major  capacities  :  ability  to 
simulate,  unambiguous  communication,  configuration  and 
performance  management,  and  easy  documentation. 

On  the  other  hand,  the  recommended  approach  is  pragmatic 
rather  than  systematic  :  care  must  be  tiUten  not  to  impair 
the  natural  flexibility  of  the  industrial  organization 
through  loo  much  formalism.  For  instance,  the  overall 
mission  definition  of  civilian  transport  aircraft  is  stable 
enough  from  a  program  to  the  next  that  it  would  not  be 
advisable  to  enforce  a  complete  and  strict  functional 
analysis  at  the  aircraft  level. 

4.2.  Domain  covered: 

The  domain  can  be  roughly  estimated  by  examining  the 
stages  required  to  deliver  a  "ready  to  go"  system. 

A  conventional  “V"  presentation  'f  development 
activities  is  given  on  Figure  3.  There  are  three  main 
stages:  design,  manufacturing  and  valid;iiion. 


Figure  3  -  System  development  cycle  and  associated 
tasks 

In  the  V  presentation,  a  validation  step  is  associated  to 
each  design  step.  Thus  presented,  the  domain  of  the  system 
workshop  is  vast  as  it  covers  the  three  above  mentioned 
phases. 

It  must  be  kept  in  mind  that  theses  stages  are  neither  truly 
chronological,  nor  independant.  Most  of  the  times,  the 
various  activites  are  canied  out  in  parallel  or  in  close 
ineration.  Additionally,  the  model  should  actually  picture 
nested  "V"s. 

For  instance.  Equipement  Manufactiring  appears  as  a 
single  activity  from  the  aircraft  manufactured  point  of 
view,  but  it  is  actually  itself  sub-structured  into  design, 
manufacturing  and  validation  siages.These  intermediate 
phases  are  not  part  of  the  primary  domain  of  the  System 
Workshop,  as  we  tend  to  sub-contract  them  entirely  :  they 
are  part  of  the  System  Workshop  visibility  domain 
however,  as  one  must  be  capable  of  fallowing  the  progress 
of  the  manufacturing  activities  and  ensuring  technical 
traceability  to  the  System  level. 

The  primary  domain  of  a  System  Workshop  should 
accordingly  be  adjusted  according  to  industrial 
organization  and  usual  worksharing  and  subcontracting 
boundaries. 

In  Aerospatiale,  it  covers  System  Definition.  System 
Architecture  and  "Equipment  Definition"  (including 
detailed  specification  of  major  functions).  System 


Validation,  and  Cettification  (more  accurately,  the  system 
part  of  the  aircraft  certification). 

4.3.  Fociislog  on  the  Design  phase 

Requirements  on  the  system  workshop  can  be  collected  by 
reviewing  the  three  main  stages  above. 

The  best  way  u>  describe  a  Systems  workshop  would  be  to 
review  the  various  stages  of  the  process  (DESIGN, 
MANUFACTURING.  VAUDATION)  to  examine,  for  each 
of  these  phases,  the  corresponding  requirements  and  the 
solutions  that  can  be  found. 

Special  emphasis  is  placed  here  on  the  DESIGN  stage  as 
this  stage  is  critical  for  the  final  product  quality  level  ; 
within  this  stage,  it  will  not  be  possible  to  examine  all  the 
steps  and  therefore  all  the  tasks  comprising  each  of  these 
steps  :  only  the  most  significant  ones  will  be  considered. 

System  defuution 

First  of  all.  the  functions  that  a  system  must  fulfilled  must 
be  defined,  and  basic  technology  choices  made.  This 
results  in  the  primary  "system  definition",  with  a  rough 
functional  bre^down. 

System  architecture  design 

In  a  first  stage,  the  criticality  levels  of  each  of  the 
functions  must  be  specified. 

From  this  point  on.  the  system  architecture  design  can  be 
undertaken  considering  : 

aircraft  specific  constraints 

-  available  (and  chosen)  technologies, 
the  natural  grouping  of  functions. 

-  the  cost,  weight,  overall  dimension  and 
maintenance  objectives,  etc... 

Re-use  of  the  system  architecture  of  previous  aircraft  as  a 
starting  point  for  the  new  one  is  a  common  and  cost- 
effective  practice  in  civil  aeroiuutics.  This  method  cannot 
apply,  though,  when  developing  a  brand  new  system,  or 
when  using  emerging  technologies.  As  an  example. 
Integrated  Modular  Avionics  (I.M.A.)  can  call  for  a 
complete  re-design  of  system  architeemre.  In  this  case,  the 
possibility  of  using  common  resources  for  several 
functions  requires  that  the  distribution  of  the  hardware 
resources  in  the  aircraft,  and  the  allocation  of  the 
functions  in  this  hardware  be  tackled  together. 

A  tool  dedicated  to  system  architecture  design  is  being 
experimented  at  Aerospatiale.  Its  name  :  AFRiCAS 
(Analyse  Fonctionnelle  et  Repartition  Interactive  pour  la 
Conception  d'Architectures  Syv  nes  :  functional 
analysis  and  interactive  allocation  fui  .ystem  architecture 
design)  is  representative  of  the  aim  pursued.  The  tool 
allows  to  describe  concurrently  the  intended  fimctional  and 
hardware  breakdowns  of  the  system.  It  then  supports  for 
each  fuiKlion  a  redundancy  choice  based  on  its  criticality 
level,  and  the  allocation  of  each  redundant  "instance"  of 
the  function  to  a  suitable  equipment,  keeping  track  of 
available  resources  and  enforcing  design  rules.  The 
resulting  "architecture"  can  be  assessed  against 
dependability  requirements,  or  simulated  (qualitative 
simulation)  to  assess  the  impact  of  specific  configurations 
or  failure  conditions.  Then,  if  necessary,  the  architecture 
can  be  amended. 
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Equipnuitt  specification  : 

This  phase  could  more  apcly  be  split  into  "Specification  of 
System  Functions"  and  “Equipments  defmition". 

An  item  of  equipment  can  be  defined  from  two  types  of 
specifications,  either  a  general  specification  which  lists 
the  functions  and  performance  required,  or  a  detailed 
specification  which  describes  the  execution  logics  of  these 
same  functions. 

The  former  is  what  is  usually  called  "Equipment 
definition". 

The  latter  can  (and  will  increasingly)  be  canied  out  at  the 
system  level  rather  than  at  the  equipment  level,  with  the 
introduction  of  IMA  and  other  distributed-system 
technologies. 

Aerospatiale  has  chosen  to  specify  in  detail  the  items  of 
equipment  intimately  linked  with  the  operation  of  the 
aircraft,  that  is  mainly,  the  critical  equipment :  fly-by- 
wire  computers,  autopilot,  man/machine  interface,  etc... 

Originally,  the  specifications  were  written  in  natural 
language  ;  the  ovenichness  of  this  type  of  language  led  to 
software  coding  errors,  as  the  specifications  could  be 
incorrectly  interpreted  by  the  programmer  analyst. 

With  this  in  mind,  Aerospatiale  developed  a  complete 
specification  and  functional  validation  workshop  based  on 
a  tool  named  SAO  (Sp&ification  Assistee  par  Ordinateur, 
Computer  Aided  Specification). 

The  major  originality  of  this  tool  is  its  graphical  language 
which  uses  a  symbol  library  and  assembly  rules  known  by 
all  electronics  and  automation  engineers.  This  language 
covers  the  field  of  operational  logics  and  closed-loop 
systems  ;  an  example  of  a  sheet  with  SAO  formalism  is 
shown  on  Figure  4. 


Figure  4  -  SAO  :  a  computer  aided  specification  "sheet" 


This  formalism  allows  : 

the  specified  function  to  be  readily  understood 
without  ambiguities,  which  avoids  most  coding 
errors, 

changes  to  be  controlled  and  therefore  the 
traceability  of  the  specification  to  be  ensured, 

a  coitsistency  check  lo  be  conducted  on  each  sheet, 
then  on  the  specification. 

Last,  SAO  allows  antomatic  coding.  This  is  not  the  least  of 
its  merits,  as  automatic  coding  has  the  following 
advantages  ; 

reduction  in  coding  errors  to  a  level  which  is 
practically  null, 

elimiiulion  of  uiut  testing, 

reduction  in  the  software  manufacturing  cycle, 
especially  the  modification  cycle. 

possibility  of  validating  the  functions  of  an  item 
of  equipment  as  early  as  the  design  stage.  This 
point  is  covered  by  the  following  paragraph. 

The  VAPS  tool  (Virtual  Anything  Prototyping  Systems) 
made  by  ihe  Canadian  company  VPl  (Virtual  Prototype 
Incorporation),  associated  with  the  SAO  tool  allows 
cockpit  display  symbologies  to  be  defined  with 
prototyping  and  animation  of  symbols. 

This  task  results  in  a  specification  for  the  equipment 
concerned.  It  is  made  up  of  : 

a  part  specified  under  SAO  and/or  VAPS  : 

*  flight  control  laws  and/or  operational  logics. 

*  equipment  input/oulput  signals. 

*  display  symbologies. 

a  more  conventional,  mostly  textual  part 
concerning,  among  other  things  : 

*  safety  requirements, 

*  physical  characteristics, 

*  environmental  constraints, 

*  etc... 

Validation  of  specifications  : 

First  of  all,  for  reasons  of  clarity,  we  shall  distinguish 
between  validation  and  verification. 

The  verification  of  a  product  consists  in  ensuring  its 
compliance  with  its  specification.  The  validation 
operation  consists  in  ensuring  that  the  product 
specifications  use  correct  and  complete.  The  importance  of 
this  operation  can  be  easily  seen  as  it  would  be  pointless 
to  know  how  to  code  a  specification  automatically, 
without  making  errors,  if  the  specification  itself  contained 
errors  or  was  incomplete. 

As  we  have  already  seen,  this  validation  operation  is 
covered  by  the  right-hand,  bottom-up  pan  of  the  V.  It  is 
usually  cairried  out  with  such  expensive  means  as  ground- 
based  integration  rigs,  aircraft  simulators  and  flight  tests. 

Although  integration  rigs  or  flight  test  are  invaluable  in 
validating  the  completed  systems  and  smoothing  out  all 
problems  of  interaction  with  the  "real"  world,  they  are 
quite  oversized  and  impractical  in  the  early  tuning-up  of 
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the  logics  of  a  system  or  in  validating  the  consistency  of 
its  functions. 

SAO  provides  a  much  cheaper  and  easy-to-use  way  to 
validate  functional  logics  and  consistency.  Drawing  up  on 
its  capacity  for  automatic  code  generation,  simple, 
"desktop"  simulation  tools  can  be  built,  allowing  the 
designer  of  a  function  to  “fly"  and  validate  “hands  on"  the 
resultant  control  software  -  within  minutes  !  If  one  of  the 
design  parameters  is  not  satisfactorily  met,  re-iterating  is 
only  a  mauer  of  hours  -  as  compared  of  a  matter  of  weeks  or 
months  if  a  new  test  equipment  had  to  be  produced. 

OCAS  (Outil  de  Conception  Assist6e  par  Simulation : 
Simulation-assisted  design  tool)  is  a  mini-simulator  of 
this  kind.  It  can  code  and  run  fly-by-wire  and  autopilot 
control  laws  in  connection  to  the  updated  model  of  aircraft 
structural  and  aerodynamic  response.  A  control  panel, 
including  mini-flight  controls  and  simulated  Primary 
Flight  Display  and  Navigation  Display  can  give  a  realistic 
"look  and  feel"  of  the  future  aircraft  controls,  while  all 
control  laws  parameters  can  be  monitored. 

This  tool  therefore  allows  the  aircraft  control  laws  to  be 
validated  at  an  early  stage  in  the  development  cycle, 
saving  long  hours  of  simulator  and  flight  tests  and  many 
design  changes. 

OCAS  does  not  take  into  account  the  hardware  aspects  -  for 
instance  failure  monitoring  and  redundancy  management. 

These  aspects  are  taken  care  of  by  another  tool,  OSIME, 
which  can  simultaneously  simulate  the  operation  of  Five 
computers,  each  computer  including  dual  redundancy  (or  a 
"Command/Monitor"  architecture). 

failure-free  operation  at  tolerance  limits, 
operation  with  failures  and  downgraded  modes, 

-  cross-computer  synchronizations, 

•  transient  effects, 

feedback  loops  with  simulated  servocontrols. 

This  tool,  which  is  extremely  powerful,  allows  several 
hundred  cases  to  be  dealt  with  overnight. 

Here  again,  automatic  coding  of  the  SAO  sheets  allows  the 
modification  cycle  to  be  reduced  to  a  few  hours. 


This  tool  is  known  by  the  name  of  OSIME  (Outil  de 
Simulation  Multi-Equipements  ;  Multi-equipment 
simulation  tool).  A  representation  is  given  on  Figure  S. 


Figure  5  -  OSIME 


Manufacturing  stage 

In  Aerospatiale's  industrial  organization,  as  Equipment 
Manufacturing  is  mostly  sub-contracted,  the  System 


Workshop  only  has  a  visibility  and  work  follow-up 
objective  for  this  stage. 

We  make  a  notable  exception  of  some  safety -critical  or 
highly  aircraft-dependent  software  packages  such  as  the 
fly-by-wire  control  laws. 

Here,  we  make  full  advantage  of  SAO  capacity  for 
automatic  code  generation,  with  a  Software  Workshop 
cofuiected  to  the  System  Workshop.  Several  such  Software 
Workshops  exist  now  in  Aerospatiale.  Eurocopter  and 
some  equipmeni/subsystem  manufacturers,  based  on  SAO 
and/or  VAPS. 

In  the  case  of  fly-by-wire  software,  ar  automatic  code 
generator  allows  70%  of  the  software  of  the  on-board 
computer  to  be  derived  from  its  SAO  specifications.  This 
tool  had  to  be  developed  with  the  same  degree  of  quality  as 
embedded  software. 

AEROSPATIALE  has  also  designed  a  test  sequence-assisted 
generation  tool.  This  tool  is  used  to  check  that  all  the 
system  functions  specified  in  SAO  language  have 
effectively  been  coded  (verification). 

Last,  a  software  configuration  management  tool  identifies 
changes  in  the  specifications  and  automatically  controls 
the  operations  required  to  update  the  software  accordingly. 

Thus,  by  simplifying  the  manual  tasks  in  the  complete 
production  cycle  and  by  close  coupling  between  the 
management  of  the  "systems"  specifications  and  the 
management  of  the  software  packages,  AEROSPATIALE 
can  comply  with  the  level  of  quality  requited  for  its  safety- 
critical  systems. 

4.4.  Focusing  on  the  Validation  phase 

We  have  already  touched  on  this  subject,  as  Verification 
and  Validation  (V&V)  ate  ongoing  cotscetns  from  the  early 
design  phases  on. 

•  Ground  tests 

Distinction  is  made  between ; 

tests  on  partial  benches  which  allow  the  opeiauon 
of  each  of  the  systems  taken  separately  to  be  tested 
with  simulation  of  the  peripheral  systems, 

tests  on  the  integration  bench  which  allow  the 
cross-operation  of  the  systems  to  be  tested.  We  try 
to  make  this  integration  bench  representative  of 
the  aircraft  as  regards  the  geometrical  shape,  the 
cables,  and  the  power  resources  such  as  the 
electrical  and  hydraulic  power  distribution  and 
generation  systems. 

tests  on  the  flight  simulator  conducted  to  validate 
the  aircraft  control  laws  and  the  failure  procedures 
in  a  real  environment.  This  simulator  is  therefore 
equipped  with  a  cockpit  similar  to  the  one  on  the 
aircraft  with  a  simulated  view  of  the  outside  world. 
Aerospatiale's  experience  on  this  subject  shows 
that  it  is  not  necessary  to  move  the  cockpit  to 
simulate  the  aircraft  movements  (for  civilian 
transport  aircrafts  at  least).  This  simulator 
therefore  differs  in  this  respect  from  the  training 
simulators  used  in  the  pilot  training  centers. 

These  tests  on  simulators  with  pilots  are  the  natural 
extension  of  those  conducted  on  the  "in-house"  simulator 
called  OCAS.  In  both  simulation  cases,  the  identity  of  the 
assessed  software  packages  is  ensured  thanks  to  the  use  of 
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SAO  and  automaiic  code  generation.  On  partial-  and 
integration-benches,  trimmed-down  SAO  specification  are 
even  used  to  simulate  peripheral  equipements. 

•  Flight  tests 

This  is  the  ultimate  phase.  In  an  aircraft  development 
cycle,  this  phase  lasts  approximately  one  year  whereas  the 
previous  phases  are.  in  general,  spread  over  several  years. 
The  tests  on  the  systems  represent  only  a  fraction  of  the 
1200  flight  hours  required  for  the  complete  certification  of 
the  aircraft. 

For  this,  the  aircraft  must  be  instrumented  with  high- 
performance  recording  systems  in  order  to  be  sure  that  all 
transient  phenomena  are  monitored.  Several  thousand 
parameters  are  thus  recorded  during  each  flight,  either 
analogically  for  large  bandwidth  signals  or  digitally  for 
the  others  ;  the  recorded  data  flow  represents  200.000  bits 
per  second  of  flight.  This  information  is  recorded  onboard 
the  aircraft  but  part  of  it  is  transmitted  directly  by 
telemetry  to  the  ground  allowing  the  test  data  to  be 
processed  in  real  time. 

As  a  typical  A340  flight  can  last  over  10  hours,  it  is  a 
amount  equivalent  to  7  GBytes  of  data  that  must  be 
processed  within  12  hours  to  extract  anomalies  and 
relevant  data  ! 

Once  again,  SAO  can  be  of  help.  DECOLO  (DECOnnexions 
LOgiqucs  :  logical  discormections)  traces  the  real  causes  of 
abnormal  results  in  logic  functions.  Searching  for  the 
causes  of  an  unwanted  warning  or  of  an  abnormal  change  of 
state  of  a  system  can  be  a  real  brain-teaser  as,  due  to  the 
asynchronous  operation  of  the  on-board  computers,  we 
cannot  easily  recover  the  time-sequence  of  the  logics 
computation  :  distinguishing  causes  from  effects  can  be  a 
tedious  cross-checking  work.  DECOLO  does  it  in  almost 
real-time  using  a  simple  backward  analysis  of  the  original 
SAO  specification. 


Figure  6-  DECOLO;  principle  of  table  analysis  for  logics 
disconnections 


4.5.  Global  tasks  covering  the  whole 
development 

Some  tasks  are  active  during  the  whole  process. 
Figure  3  idemines  four  of  these  tasks  : 


•  Corportue  memory 

Past  experietree  or  the  company's  memory  must  exist  in  an 
easily-accessible  and  user  friendly  form,  this  is  rarely 
achieved. 

From  the  information  required  by  the  designer,  we  must 
single  out  : 

The  technical  directives  and  the  regulatory  texts  : 
the  pile  of  documents  covering  all  the  systems  of 
an  aircraft  stands  more  than  6  feet  high  !  In  fact, 
the  designer  needs  a  guide  to  find  the  information 
that  he  requires  in  all  this  undergrowth. 

The  selective  experience  which  results  from  actual 
debugging  cases  or  even  irreidents  or  accidents.  To 
perpetuate  this  experience,  typical  cases  are 
volunteered  and  described  "on  the  run"  in  a 
database,  with  entry  forms  kept  as  simple  as 
possible.  From  that  database,  a  team  of  experts 
extracts  applicable  'Rules",  with  a  procedure  fur 
following  up  the  applications 

The  product  know  ledge  :  technical,  factual  data  of 
course,  but  mure  important  the  "whys"  and  the 
“thcrefores",  the  technical  justifications  for  the 
design. 

The  know-how  or.  again,  the  expertise  which 
makes  up  the  company's  culture  and  ways  of 
reasoning  ;  fur  that  reason,  the  System  Workshop 
also  includes  a  extensive  program  of  .  mutual 
teaching  or  training. 

Aerospatiale  is  developing  a  program  called  MERE  (Mise 
En  Regie  de  TExp^rience  :  experience  set  inu)  rules)  which 
is  a  global  corporate  memory  project  taking  into  account 
the  vsaioas  above  mentioned  aspects. 


Figora  7  -  Corporate  memory  organization  ; 
MERE  :  experience  set  into  rules 


Figure  7  explains  the  various  components  of  this  project. 
This  perpetuation  of  the  company’s  know-how  seems  to  us 
to  be  fundamental ;  it  applies  upstream  of  and  throughout 
the  complete  design  process. 

•  Documentation  chain  : 


Today,  most  of  the  documents  produced  are  not  always  deri¬ 
ved  from  one  another,  there  is  no  systematic  chaining 
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between  documents,  nor  between  design  and 
documentation. 

Lacking  methodology  and  standards,  the  documentation  of 
complex  systems  soon  becomes  difficult  to  control. 

To  produce,  manage  and  use  the  numerous  documents  which 
result  from  the  design,  manufacture  and  validation  phases 
of  a  system,  we  need ; 

a  documentation  model.  This  model  can  be  built  by 
analyzing  the  development  process  in  term  of 
activities,  information  produced  by  the  activities 
and  their  use,  and  logical  &  chronological 
grouping  of  these  informations  ; 

document  writing  guidelines,  and  a  common 
exchange  formal  for  structure  documents. 

document  chaining  possibility, 

document  configuration  and  information 
traceability  marugement. 

This  program  is  basically  in  agreement  with  the  aims  of 
the  CALS  (Computer  Aided  Logistic  Systems)  initiative 
promoted  by  the  US  DoD  (Department  of  Defence) ;  most 
standards  promoted  by  CALS,  such  as  SGML  (Standard 
Generalized  Mark-up  Language),  are  under  sntdy.  SGML  is 
already  used  in  the  Aerospatiale  Product  Support 
department,  and  is  a  basis  for  the  future  on-board 
Electronic  Library  System.  Its  use  in  support  of  design 
documentation  is  promising,  but  dependent  on  a  thorough 
methodological  analysis. 

•  Dedicated  system  workshop  host  environment 

There  is  little  difference  between  the  host  environement  of 
a  software  workshop  and  that  of  a  systems  workshop.  In 
both  cases,  the  aim  is  : 

to  supply  a  user-friendly  interface  in  order  to  guide 
the  user  when  accessing  the  various  tools  and 
functionalities  of  the  workshop. 

to  manage  the  objects  which  are  : 

•  proper  to  the  workshop  itself. 

•  or  produced  by  the  workshop  tools. 

to  create  or  manage  the  links  between  all  these 
objects  : 

•  either  for  the  traceability  of  the  activities, 

•  or  to  make  up  the  documentation. 

to  activate  the  tools  and  support  their 
communications 

to  provide  project  management  facilities  with 
access  rights, 

to  communicate  with  other  workshops  (in 
particular,  partners'  and  Equipment  Manufacturers' 
Workshops), 

to  support  the  company's  procedures  and 
terminology. 

More  than  a  piece  of  software,  a  System  Host  Environment 
is  mostly  an  set  of  corporate  standards.  We  cannot 
overemphasize  the  importance  of  harmonization  and 
consistency  as  without  it  the  designers'  tools  would 
flourish  with  the  same  logic  as  that  governing  the 
distribution  of  poppies  along  the  roadsides  in  the 
springtime. 


To  develop  this  type  of  structure,  we  need  widely-used 
standards  and  interfaces  to  be  able  to  accommodate  a  large 
lange  of  toots  available  on  the  market.  For  example,  the 
PCTE  (Portable  Common  Tool  Environment)  standard 
already  used  for  software  workshops. 

This  standardization  is  even  more  necessary  as  we  are 
compelled  to  work  in  ever  closer  cooperation.  This  is  the 
case  for  Aerospatiale,  within  the  set^  of  the  European 
civil  aircraft  programs  such  as  Airbus  and  ATR. 

S  .  ENCOURAGING  RESULTS 

A  systems  workshop  is  being  gradually  set  up  at  the 
Aerospatiale  Aircraft  Division.  At  the  time  of  writing,  still 
a  lot  remains  to  be  do.-ie,  in  particular  at  the  systems  host 
environment  level.  Also,  the  scope  of  SAO  must  be 
extended  to  new  types  of  functions  such  as  data  bank 
management,  scientific  calculations,  etc...  and,  on  the 
other,  by  interfacing  SAO  with  functional  analysis  tools 
capable  of  complementing  it  upstream. 

In  spite  of  these  needed  improvements,  the  contribution 
made  by  some  of  these  tools  can  be  mesured. 

SAO 

Figure  8  shows  the  improvements  achieved. 


Aircraft 

A3I0 

A320 

A340 

Mumber  of  Digital 
Units 

77 

102 

115 

Size  of  on-board 
loftware  (MBytes) 

4 

10 

20 

Encoding  errors  for 
100  kBvtes 

a  few 
hundreds 

a  few 
dozen 

<10 

Note;  On  the  A340,  the  systems  benefilting  from 
automatic  encoding  are  : 

•  fly-by-wire  ;  7(Mt 

«  Automatic  Right  Control;  70% 

♦  Display  Computers  ;  S0% 

»  Warning  and  Maintenance  systems;  40% 

Figurn  8  -  SAO  impact  of  software  coding  errors 

On  the  A310.  when  the  specifications  were  written  in 
natural  language,  there  were  hundreds  of  coding  errors  in 
software  packages  with  a  size  of  100  Kbytes  ;  on  the 
A320.  thanks  to  the  use  of  SAO,  this  number  was  reduced 
to  a  few  tens  of  errors  and,  today,  on  the  A340,  by  adding 
automatic  code  generation,  the  number  of  errors  is  less 
than  ten. 

The  impact  of  OCAS  and  OSIME  on  specification  errors  is 
comparable,  although  no  figure  is  available  yet  as  these 
tools  are  currently  being  used  on  the  A340/330  program. 

These  results  show  that  the  generation  of  complex 
software  packages,  which  was  rightly  considered  difficult 
during  the  last  ten  years,  is  today  a  problem  well  under 
control  at  Aerospatiale. 

DBCOLO 

Automatic  diagnosis  of  disconnections  endloi  warnings  is 
an  important  step  forward  in  the  analysis  of  tests  on 
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Systems  with  complex  operational  logics.  This  tool 
provides  good  results  in  80  %  of  the  cases,  in  less  than  3 
minutes  of  analysis  compared  with  the  many  hours  of 
manual  analysis  required  on  previous  aircraft. 

CIRCE 

The  contribution  made  by  CIRCE  affects  two  fields  which 
are  data  quality  and  the  development  cycle  : 

•  the  quality  of  the  definition  of  electric  cables  has 
been  considerably  increased  to  reach  the  following 
percentage  :  99  %  of  the  cable  defini.ion  is  conect 
following  the  Hrst  data  processing  operation. 

•  the  processing  cycle  for  a  complete  definition,  has 
been  reduced  from  24  to  7  days. 

Note  that  a  CIRCE  operation  today  calculates  the 
deflnition  of  230,000  different  electric  cables,  each  one  of 
them  being  described  by  50  parameters. 

i.  CONCLUSION:  REQUIREMENTS  FOR 
THE  YEAR  2000 

Our  aim  in  this  document  was  to  make  the  reader  aware  of 
the  benefits  of  having  a  systems  workshop  to  design, 
produce  and  validate  complex  systems. 

Much  more  than  an  exhaustive  description  of  such  a 
workshop,  the  aim  of  this  document  was  to  promote  the 
procedure  leading  towards  this.  Such  an  approach  lives  up 
to  the  aim  pursued.  Over  and  above  the  economical  and  lead 
time  aspects,  which  alone  justify  the  setting  up  of  such  a 
procedure,  its  fundamental  strategic  aspect  must  be 
underlined  : 

On  the  one  hand,  the  communication  and  information 
transfer  aspect,  which  is  one  of  the  goals  of  this  project,  is 
the  key  to  multi-partner  cooperations. 

On  the  other  hand,  such  a  systems  workshop  is  the 
cornerstone  in  the  development  of  complex  systems.  With 
this  asset,  Aerospatiale  is  well  on  its  way  to  mastering 
the  complex  systems  of  (he  year  2000  and  beyond. 


Discussion 

Question  S.  GROISIL 

Les  logkiels  de  simulatioa  et  le  logiciei  de  g^ndraiioa  de  code  doiveni-its  due  cenitite?  Si  oui.  comment  ie  sont-ils? 
Reply 

La  simulation  est  aujouid'hui  un  moyen  d'efficacii^  inteme  ei  ne  se  substitue  pas  aux  moyens  de  vaiidatioa  et  de 
ceftificadon  classiques. 

Les  cfaaSnes  de  Uvraison  et  de  g^ntouion  de  code  automatiques,  elles,  ont  un  impact  important  sur  la  certification  du 
logiciei  T^sultanL  La  ptocMute  accept^  aujouidliui  est  de  les  ’qualiner’  sur  la  base  d»  monies  contrainies  que  ie 
logiciei  produit ;  applicaiion  de  la  DO  178  k  leur  ddveloppement. 

Question  K.  BRAMMER 

You  showed  considerable  decrease  of  coding  errors  for  a  given  size  of  software,  for  the  software  of  the  Airbus  family. 
Did  you  practice  software  re-use  from  one  Airbus  type  to  the  next?  If  yes,  can  you  comment  on  the  contribution  of  re-use 
to  the  decrease  in  coding  errors? 

Reply 

Re-use  on  object  code,  or  even  of  programming  language  source-code  has  little  meaning,  as  typical  hai-dware 
components  may  evolve  greatly  from  a  programme  to  the  next  (5  years  is  typically  the  span  of  1  or  2  generations  of 
processors). 

On  the  other  hand,  re-use  of  SAO  specification  is  frequent,  either  through  re-use  and  evolution  (as  from  A320  to  A340  or 
ATR>  or  through  actual  commonality  ( A340  and  A330  specifications  ate  mete  versions  of  a  single  configuration 
environment,  with  extensive  community  of  SAO  "sheets’). 

Note  that  the  library  of  SAO  symbols  is  gradually  growing.  Each  symbol  actually  stands  for  an  agreed-upon  software 
element  specificatioo  and  a  re-usable  software  d^gn.  Defming  a  new  library  symbol  is  a  very  profitable  -if  heavy- 
investment  : 

1)  as  a  standard  element,  agreed  by  both  specifier  and  software  engineer,  it  enhances  the  autonomy  and  efficiency 
of  both, 

2)  its  design  and  coding  only  have  to  be  done  and  validated  once  in  a  progranune  -  or  for  several!  programmes  - 
even  though  it  may  appear  in  hundreds  of  places  in  the  specification.  The  level  of  confidence  achieved  in  the 
overall  library  is  such  that  unitary  testing  is  no  more  required  for  most  software  versions  produced, 

3)  discrepancies  between  simulation  software  md  on-board  software  are  minimal.  They  ate  mainly  sequencing 
non-determinations  and  coding  performance.  The  latter  can  be  measured  and  corrected  if  necessary.  Tte  former 
can  be  specified  (but  bewtne  of  over-specification!). 

Roughly,  automatic  code  generation  reduced  coding  errors  to  those  present  in  the  symbols  -  and  a  lot  of  work  can  be 
invested  in  their  verifictuion,  so  this  is  almost  nil.  The  use  of  a  libra^  of  symbols,  stable  from  a  progranune  to  the  next, 
makes  software  specifiemion  unambiguous  and  prevents  most  oode-de«gn  errors. 
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Specifications  Executables  des  Logiciels  des  Systemes  Complexes 


F.  DELHAYE,  D.  PAOUOT 
SFIM  Industries  Groupe  Avionique 
13,  Avenue  Ramolfo  Gamier 
91344  MASSY  CEDEX 
France 


1.  Resume 

Les  technologies  num^riques  ont  pris  une 
importance  croissaiite  ^  chaque  g^n^ration  de 
systdme  de  controle  de  vol.  Lc  logiciel  temps 
rdel  embarqud  accomplit  maintenant  I'essentiel 
des  fonctions  de  ces  syst&mcs. 

La  ndcessitd  d'industrialiser  la  production  de 
ce  logiciel  s'est  rapidement  imposde.  SFIM 
Industries  a  done  mis  eu  place  une  ddraarche 
visant  ^  outiller  progressivement  chacune  des 
phases  du  cycle  de  vie. 

Le  pilotage  des  hdlicoptdres  est  caraetdrisd  par 
une  complexity  intrins^que.  De  plus 
I'architecture  redondante  des  syst^mes  de 
pilotage  augmente  cette  complexity. 

La  spyciftcation  de  tels  syst^mes  est  done  une 
tachc  tris  difficile.  Or  cette  phase  de 
dyvelopperaent  revgt  une  importance 
particuliyre  car  les  erreurs  de  spycification  ne 
sont  gyndralement  dytectyes  que  dans  les 
phases  ultdrieures  du  dyvelopperaent,  ce  qui 
induit  des  couts  de  correction  Mevds. 

11  convient  done  de  s'assurer  au  plus  tot  de 
I'exactitude  et  de  la  validity  de  la  spycification. 

Dans  le  cadre  de  ses  activitys  de  Recherche  et 
Dyvelopperaent  en  matidre  d'avionique,  SFIM 
Industries  a  entrepris  d'dvaluer  I'apport  des 
techniques  de  spycification  exycutable  dans  le 
cycle  de  dyvelopperaent  des  systdmes 
complexes. 

Diffyrentes  techniques  ont  6t6  analysdes 
(analyse  structurye,  langages  synchrones, 
systdmes  experts)  et  parmi  ceUes-ci  deux  ont 
fait  I'objet  d'expyrimentation. 

Ces  techniques  ont  permis  de  construire  des 
spycifications  et  de  les  valider  avec  des  degrds 
de  compiytude  plus  ou  moins  importants. 

L'intyr6t  de  ces  techniques  a  dtd  clairement 
dymontry.  Elies  apparaissent  comme  des 
yidments  majeurs  d'une  dymarche  organisde  de 
rdduction  du  cout  de  dyvelopperaent  des 
logiciels  des  systferaes  coraplexes. 


Gloswiit  Twbnittue 

.mode  supyrieiir  asservissement  de 
pilotage  destiny  ^  assurer  le  dyplacement  de 
i'hyiicoptyrc  sur  une  trajectoire  dans 
I'espace. 

.directeur  de  vol  ;  fonction  de  visualisation 
permettant  de  donner  des  consignes  de 
pilotage  k  ryquipage  par  I’intermydiaire  de 
barres  de  tendance. 

,axe  de  pilotage  ;  axes  de  rdfdrence 
(tangage,  roulis,  lacet,  puissance)  autour 
desquels  s'effectue  le  pilotage  de  la 
machine. 

.trim  :  actionneur  yic^  adcanique 
permettant,  k  partir  d’ordres  yiectriques,  la 
commande  de  vol  de  la  machine. 

,arniement  :  Tarmement  d'un  mode  est  une 
phase  de  pryparation  du  mode  durant 
laquelle  le  mode  n'a  aucune  action  sur  le 
pilotage.  Un  mode  army  ne  s'engage 
effectivement  que  lor'^ue  les  conditions  de 
capture  sont  vyrifides 

.capfiire  yvdnement  produit  par  la 
dytection  de  la  prdsence  d'un  faisceau  de 
guidage. 

3.  G4n4ralitfe 

SFIM  Industries,  spycialLste  mondial  du 
contrdle  de  vol  des  hyiicopteres,  est  une  des 
premieres  firmes  fran9aises  d'yquipements 
ayronautiques  et  de  ddfense. 

Elle  dyveloppe  dans  ce  cadre,  des  systdmes 
dont  la  complexity  et  la  sycurity  vont  croissant 

3.1  Les  probfemes  de  Oualite  des  loeidels 
embaraufe 

Aujourd'hui,  presque  tous  les  dquipements  et 
systdmes  yiectroniques  de  bord  udlisent  ou 
utiliseront  des  calculateurs  numdriques. 
Contraireraent  k  Icurs  prdddeesseurs  d  la 
preraidre  gdnyration,  ils  sont  maintenant 
intygrds  dans  des  architectures  entidrement 
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nouvelles  et  conunuhiquent  entie  eux  via  dea 
liaisons  num^riques. 

Les  possibilitds  offeites  par  les  syst^mes 
num^riqiKS  permettent  d'int6grer  des  quandt^s 
importantes  de  fonctions.  De  plus  pour  les 
syst^mes  dc  vol,  la  s^curit^  est  assuree  par  la 
mise  en  place  de  syst^mes  redondants  rd^sant 
des  surveillances  crois^es. 

Tout  cela  conduit  h  une  augmentation  de  la 
sophistication  des  syst&mes. 

La  maltrise  de  leur  comportement  est  tendue 
difficile  par  I'accroissement  des  possibilit^s 
d'6v6neraents  simultan^s. 

3.2  Le  cycle  de  vie 

Les  couts  de  d^veloppement  d'un  syst^me 
peuvent  etre  r^partis  sur  les  trois  phases  de 
dtiveloppement  suivantes: 

A)  A  partir  de  I'expression  de  besoin  du  client, 
dtablissement  de  la  specification  du  syst^me  et 
d^veloppement  de  celui-ci  conformement  i  la 
specification  (cycle  de  developpement). 

B)  Correction  de  la  specification  et  reprise  du 
cycle  de  developpement  jusqu'^  obtension  d'un 
systeme  repondant  aux  tesoins  du  client 
(recette  ou  mise  au  point  operationnelle). 

C)  Correction  des  probldmes  trouves  en 
exploitation  (maintenance). 

•  Le  cout  de  la  phase  A  est  important,  mais 
aujourd'hui  bien  identifie  et  maitrise  lorsque 
Ton  parcourt  une  seule  fois  le  cycle  de 
developpement  et  de  validation  du  systieme. 

•  Le  cout  de  la  phase  C  est  mal  ceme  a  priori, 
mais  on  espdie  toujours  que  la  qualite  du 
developpement  sera  telle  qu'il  restera  minime. 

•  Le  cout  de  la  phase  B  peut  8tre  tiis 
important  et  surtout  difficilement  maltrisable. 
n  depend  de  dialogues  entre  difierents 
intervenants  et  la  formalisation  est  souvent 
difficile. 

La  sophistication  des  syst^mes  fait  que  la 
specification  ne  reflate  pas  toujours 
compietement  et  suffisamment  les  besoins  du 
client  et  ceci  n'est  vu  qu'a  la  reception  du 
systeme  ou  lots  de  la  mise  it  disposition  de 
Tutilisateur  final. 

Tout  ceci  conduit  ^  reparcourir  compietement 
le  cycle  de  developpement 
La  remise  en  cause  du  travail  effectue  a  de 
plus  un  impact  psychologique  non  negligeable 
sur  les  equipes  de  developpement 


C'est  done  sur  cette  phase  que  nous  avuns 
decide  de  concentrer  nos  efforts  et  pour  cela 
mettre  en  place  des  moyens  pour  ameiiorer 
retablissement  de  la  specification. 

3.3  Definition  rritferes  de  oiialite  ites 
snedfleations 

Une  specification  est  faite  pour  permettre  la 
communication  entre  les  divers  intervenants 
du  projet: 

-le  cUent  (celui  qui  finance). 

-le  specifieur  (celui  qui  formalise  le  besoin) 
-le  realisateur  (celui  qui  developpe). 
-I'utilisateur  (celui  qui  doit  s'en  servir). 

-le  mainteneur  (celui  qui  herite  des 
probiemes). 

Chacun  a  une  approche  particuliere  de  ce 
document : 

le  client  et  Yutilisateur  ont  un  point  de  vue 
exteme  du  produit  Us  d^sirent  voir  r^aliser  le 
produit  qu'Us  ont  imagind. 

le  specifieur  doit  par  dialogue  avec  le  client 
comprendre  son  besoin  et  le  formaliser  pour 
les  6quipes  de  d6veloppement. 

le  realisateur  et  le  mainteneur  ont  un  point  de 
vue  interne  du  produit.  Us  ddsirent  un 
document  clair  pour  que  les  choix  lors  de  la 
conception  du  systdme  soient  compatibles 
avec  la  destination  du  produit. 

U  importe  done  que  cette  specification  soil : 

-.structurec  et  homogfene  :  une  specification  est 
une  reference  et  comme  pour  tout  document  de 
ce  type  eUe  doit  etre  organisee  suivant  un  plan 
logique  qui  facilite: 

la  lecture. 

la  consultation  ponctuelle. 
la  modification. 

-adaptee  ^  ses  lecteurs  :  les  differents  lecteurs 
ont  des  preoccupations  et  des  cultures 
techniques  souvent  differentes.  11  faut  pourtant 
que  la  specification  permette  k  chacun  de 
comprendre  les  objectifs,  les  contraintes,  les 
possibilites  existantes  et  les  potentialites  du 
systime. 

-coherente  :  U  est  difficile  de  rdaliser  un 
produit  dont  la  specification  est  contradictoire. 

-complete  et  sans  ambieuites  :  U  est  necessaire 
de  ne  pas  laisser  le  concepteur  faire  des 
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interpi^tatioiis  ou  des  suppositions  sur  la 
sp&nfication. 

-conforme  aux  souhaits  de  1‘utilisateur  final :  la 
specification  dtant  la  premiere  etape  de  la 
realisation  du  produit,  U  est  important  que  le 
speciAeur  ait  correctement  traduit  les  de^  de 
son  client 

Si  la  ndcessite  d'etablir  des  specifications 
avant  de  realiser  un  produit  est  largement 
reconnue,  les  precedes  pour  conduire  une  telle 
activite  lestent  peu  eiaboies  et  surtout  nes 
divers  selon  les  environnements.  La  fa9on  la 
plus  lepandue  demeuie  la  redaction  en  langage 
naturel. 

Face  k  cette  approche  intuitive  il  existe  des 
methodes,  et  des  outils  associes,  venant 
assister  le  specifieur. 

Ces  methodes  sent : 

-les  specifications  semi-fotmelles  qui  utilisent 
un  "langage  de  specification"  textuel  ou 
graphique,  langage  dote  d'une  syntaxe  en 
general  precise  et  d'une  semantique  souvent 
assez  faible,  mais  suffisante  pour  peimettre 
I'autoraatisation  de  certaines  verifications. 

-les  specifications  formelles  exprimees  dans 
un  langage  k  syntaxe  et  k  semantique  precise, 
construit  sur  une  base  theorique  solide  et  qui 
permettent  des  validations  automatisees. 

Elies  permettent  d'assurer  la  coherence  et  la 
compietude  de  la  specification.  Ce  formalisme 
peut  6tre  suffisamment  precis  pour  etre 
interprete  par  I'ordinateur  et  ainsi  foumir  une 
specification  executable  (maquette). 

Cette  maquette  liee  ^  une  simulation  de 
I'environnement  du  systdme  peut  peimettre  ^ 
I'utilisateur  final  d'observer  le  comportement 
de  son  futur  produit. 

Celui-ci  peut  done,  dds  la  phase  de 
specification,  demander  les  rectifications  qui 
lui  semblent  necessaires. 

L'etablisseraent  d'une  specification  avec  les 
methodes  envisagees  sera  realise  au  moycn  de 
quatre  activites 

.Modeiisation:  activite  de  construction  du 
module  de  besoins 

.Simulation:  activite  d'execution  et  de  mise  au 
point  du  module  (aspects  internes  du  module) 


.Proimypage:  activite  de  generation  d'un  code 
executable,  image  du  module 

•Validation:  activite  de  verification  du 
module.  Elle  peut  etre  faite  soil  sur  le  modeie, 
soit  sur  le  prototype. 

Pour  chacune  de  ces  activites  un  ensemble  de 
criteres  a  ete  idendfie  pour  determiner 
I'efficacite  de  la  methode  choisie. 

3.3.1.  Aedvite  de  modeiisation 

la  facilite  de  descripdon  :  adequadon  de  I'oudl 
k  decrire  des  points  pardculiers  de 
specificadon,  qu'ils  soient  sequendels  ou 
combinatoires. 

la  facilite  de  comprehension  :  apdtude  du 
document  genere  ^  decrire  une  sf^ificadon 
pour  un  lecteur  final  non  forme  4  la  methode. 

la  verificadon  stadque  de  la  compietude  : 
possibilites  offertes  par  I'oudl  pour  detecter  les 
erreurs  et  les  manques. 

la  facilite  de  modificadon  :  le  changement  d'un 
element  de  specificadon  ne  doit  pas  entrainer 
pour  le  specifieur  une  charge  de  travail 
dispropordonnee. 

la  facilite  d'evolurion  :  I'addidon  de  nouvelles 
fonedons  doit  Stre  simple. 

la  qualite  de  la  documentadon  produite  : 
possibilite  d'avoir  un  plan-type  conforme  ^  des 
normes,  comrae  par  exemple  la  DoD  2 167 A. 

Cet  ensemble  de  critdres  devrait  peimettre 
d'assurer  la  coherence  de  la  specificadon  et 
d'eviter  les  erreurs  de  la  part  du  conceptcur. 

3.3.2.  Aedvite  de  simuladon  et  Drototvpage 

Les  criteres  associes  &  ces  deux  acdvitds  sont 
idendques. 

la  visualisation _ dvnamique  :  interface 

graphique  destine  ^  presenter 
ergonomiquement  les  donnees  representatives 
du  systdme  lors  de  la  phase  de  verification 
dynamique. 

rinterfa9age  avec  des  elements  exterieurs  au 
modeie  :  possibilites  offertes  par  I'oudl  de 
coupler  plusieurs  modules  entre  eux,  pour 
avoir  la  descripdon  complete  d'un  sys^me 
compose  de  plusieurs  sous-ensembles  dej^ 
modeiises. 
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I’interfayage  avec  des  langaees  de  haut-niveau: 
possibiht^s  offertes  par  I'outil  d’inteifacer  le 
module  avec  des  simulations  d'environnement 
existantes  dcrites  dans  des  langages  de  haut 
niveau. 

le  temps  de  rdoonse  du  svstfeme  :  rapiditd  de 
I'outil  II  calculer  I'dtat  syst^me  suivanL 

Get  ensemble  de  entires  devrait  permettre  de 
presenter  au  client  une  image  fiddle  de  son 
futur  produit  et  de  pouvoir  ddfinir  un  protocole 
de  recette  du  produit. 

3.3.3.  Aedvitd  de  validation 

la  verification  dvnamiQue  du  moddle  :  en 
mode  interactif  ou  en  mode  "batch",  simuler 
des  actions  sur  les  entrdes  du  moddle  et 
observer  son  comportement  ainsi  que  son  dtat 
interne. 

la  comnldtude  des  tests  :  verification  quo 
chaque  dldraent  de  specification  a  6t6  utilise 
par  au  moins  un  test  applique  au  moddle. 

3.4  Rappel  de  la  strategie 

Une  etude  a  ete  mende  pour  rcchercher  des 
solutions  industrielles  h  notre  probldrae  de 
specification. 

Pour  simplifier  le  probldme  nous  avons 
considere  que  les  methodes  de  specification 
couramment  utilisees  dans  nos  systdmes 
appartiennent  ll  deux  categories. 

-  Description  des  aspects  coraportementaux 
(etats  du  systdme) 

-  Description  des  aspects  transformationnels 
(calculs  et  asservissements) 

Cette  demiere  a  dejil  fait  I'objet  de  travaux  qui 
nous  ont  amend  4  ddvelopper,  il  y  a  quelques 
anndes,  un  formalisme  graphique  de 
description  de  ces  aspects.  C’est  done  It  la 
premiere  categorie  que  nous  allons  nous 
interesser. 

3.5  Presentation  des  methodes  evaludes 

SI^IM  Industries,  aprds  avoir  mend  des  dtudes 
sur  les  diffdrentes  mdthodes  de  specification 
suivantes: 

-  Systdmes  Experts  (G2,  KEE) 

-  Engages  synchrones  (ESTEREL, 
LUSTRE) 

-  Analyse  structurde  (ASAr  "" 
TEAMWORK/SIM,  STATEMATE) 


a  decide  d'evaiuer  plus  precisdment  deux 
mdthodes  de  specification  plutot  novatrices. 

-  La  mdthode  de  HAREL  supportde  pv 
I'outil  STATEMATE,  ddveloppe  par  I-logix 
et  distribud  en  France  par  Anticyp. 

-  Une  mdthode  it  base  de  systdme  expert  et 
de  representation  orientde  objet,  supportde 
par  I'oudl  G2  de  Gensym,  distribud  par 
FRAMENTEC-COGNTTEC. 

3.6  PtfetntatiOD  de  la  able  support  de 
revaluation 

La  cible  qiplicative  de  ces  mdthodes  a  dtd 
fixde  k  un  sous-ensemble  de  la  logique 
opdrationnelle  d'un  pilote  automatique  pour 
heiicoptdie:  la  function  de  gestion  des  modes 
supdrieurs  de  pilotage. 

Cette  cible  est  lestrcinte  mais  d'une  complexite 
suffisamment  representative  pour  pouvoir 
appidcier  les  qualitds  des  deux  mdthodes. 

4.  Evaluation  de  STATEMATE 

4.1  Rapnds  sur  la  mdthode  de  HAREL 

Entre  1983  et  1985,  David  Harel  a  erdd  le 
concept  de  Statechart,  puis  une  mdthode  de 
specification  complete  portani  son  nom.  Cette 
mdthode  est  le  prolongement  naturel, 
formalise  et  graphique,  des  mdthodes  d'analyse 
structurde  appUqudes  aux  probldmes  temps 
rdel. 

Statemate  en  a  dtd  en  1987  la  premidre  et 
demeure  ^  ce  jour  la  seule  implementation. 

La  mdthode  de  Harel  et  I'outil  Statemate 
permettent  de  ddfinir  un  systdme  selon  trois 
types  de  vues : 

fonctionnelle  (activity-charts)  et 
comportementale  (statecharts)  e'est  la 
specification  proprement  dite, 
enfin  stnicturelle  (module-charts)  ic'est  le 
debut  de  la  conception. 

...Ces  vues  sont  ddfinies  comme  des 
ehiboitements  non  limitds  de  boites  (resp. 
activitds,  dtats,  modules)  relides  par  des 
fidches,  reflet  prdcis  de  la  hidrarchie  du 
systdme. 

Uhe  boitc  peut  ette  clle-meme  dderite  par  un 
dia^ramme  (chart):  c’est  la  facilitd  box-is-chart 
(cettc  facilitd  permet  I'encapsulation). 

Les  boites  sont  dotdes  de  noms  et  les  fldches 
de  IjdKls. 

Sur  les  ?Jdches  (flux  et  transitions)  peuvent 
ctre  placds  des.  connecteurs  simples  ou 
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multiples  k  s^mandqiw  precise 
(ctHTc^ndaoce,  composition,  etc ). 

4. 1.1.  -  Activitv-chart 

Ce  type  de  vue  pennet  de  ddfinir  les 
decompositions  et  les  dchanges  fonctionnels. 


I  ACnviTt_PIU)IClPAL*  -  I 

Formalisinc  de  I'Activitv-diart 


Pour  cela,  il  utilise  ; 


Ces  informations  peuvent  etre  structurees. 
Seuls  les  flux  de  contrdle  correspondant  k  la 
connaissance  et  ^  la  commande  de  I'etat  d'une 
activite  par  I'acdvitf  de  contrdle  sont 
implicites. 

4.1.2. -Statcchan 


Un  statecfaart  deflnit  le  comportement 
hierarchise  des  fonctions. 


FormaHsme  du  Statechart 


.des  bttftes  (activites) : 

-consommant  ou  mettant  k  disposition  des 
informations : 

♦boites  rcctangulaires  ;  les  activates 
extemes  (pointiliees)  et  internes 
(continues), 

*boites  arrondies  :  les  activites  de 
contrdle,  dont  chacune  est  lide  k  un 
statechart,  qui  ont  pour  idle  de 
connaitie  et  definir  le  comportement 
de  leurs  soeurs  (exclusivement)  et 
d'arrdter  leur  mere, 

-simples  lieux  de  transit  d'infoimation  :  les 
stockages  de  donnees  (boites  mi-pointiliees, 
mi-continues) ; 

.des  fiedies  (flux  d'infomiation) : 

-  mettant  4  disposition; 

.des  evenements(  fugidfs,  disponibles  k  un 
instant  et  perdus  aussitdt,  meme  non 
consommds)  ou  des  conditions  et  des 
donndes  (persistantes). 

*de  contrdle  (fieches  pointiUdes), 

*de  donndes  ou  mixtes  (fieches 
continues). 


Pour  cela,  il  utilise  : 

.des  bttftes  arrondies  (etats) ; 

-un  etat  pcut  contenir  des  etats  "ou" 
dans  lesqucls  le  systtme  ne  peut  se 
trouver  quc  successivemcnt ; 

-un  etat  scinde  par  un  ou  plusieurs 
pointiUes  definit  deux  ou  plusieurs 
etats  "et"  dans  lesquels  le  systeme 
peut  se  trouver  k  la  fois  ; 

Ces  notions  peuvent  se  combiner  au  choix  ce 
qui  pennet  clarte  et  compacite;  les  etats 
peuvent  Stre  dotes  de  reactions  stadques 
produisant,  sur  dedenchement,  des  acdons 
independantes  de  toute  transidon. 

.des  nedies  (transitions) : 
leur  label  (evenement[condidon]/acdon) 
comporte  un  declencheur 

(evenement[condidon])  qui  decide  du  passage 
(instantane)  d'un  etat  ^  I'autre  et  une  acdon 
(action)  qui  est  produite  lors  de  ce  passage. 

Les  evenements  et  conditions  peuvent  Stre  des 
combinaisons  logiques  d'evenements  ou 
conditions. 

Les  actions  peuvent  etre  des  ensembles  (non 
ordonnes)  d'actions  ;  elles  peuvent  aussi  etre 
conditionnees  par  d'autres  d^lencheurs. 


Les  entries  par  d^faut  et  tea  coanecteurs 
d'historique  et  de  termixiaison,  compl^tent  la 
s6mantique  des  transidona. 

Le  tempa  n'intervient  que  de  fa(on  explicite  et 
aoua  la  forme : 

-  d'tfv^nementa  diff6r6a. 

-  d'acdona  programm^ea, 

-  <k  lien  global  entre  paa  (aimuladon, 
testa  dynamiques)  et  unit^  de  temps. 

Les  liens  entre  statechart  et  activity-chart 

sont  op6r6s: 

.par  des  ^v^nements 
started  (acdvity). 
stopped  (acdvity),etc. 
par  des  conditions 
acdve(acdvity),  etc. 
et  par  des  actions 
start !  (activity) 
stop  !  (activity),ctc.) 
plac^ : 

-sur  les  labels  des  transitions, 

-dans  des  reactions  statiques  des  ^tats; 

.par  des  indications  de  coiT61ation  entre  dtats 
et  activit6s 

activity  throughout  state, 
activity  within  state. 


Un  module-chart  permet  Tallocation  des 
fonctions  et  des  flux. 


!  MODULE  CXTCKItE 
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Un  module-chart  ressemble  H  un  a'tiv’ry-chart 
mais  n'a  pas  de  module  de  contrdir  C'iiaque 
module  impl^mente  une  ou  plusieurs  activit^s, 
de  sorte  qu'il  y  ait  un  rccouvrement  complet  de 
I'ensemble  de  celles-ci,  4  I'exception  des 
activity  de  contrdle. 


Les  flux  peuvent  etre  regroup6s 
(implementation)  differemment  mais  leur 
conlenu  est  coherent  avec  celui  des  flux  des 
activity-charts. 

Cette  implementation  constitue  le  lien  entre 
modhile-chart  et  activity-chart. 


Un  dictionnaire  de  donnees  rasserable  les 
informations  (  et  leurs  relations)  des 
diagrammes  du  modeie  hierarchises  par  ces 
liens  d'imbrication,  de  description  ou 
d'impiementation.  Chaque  element,  graphique 
ou  non,  du  mo<j^le  appartient  ^  un  diagramme. 
Son  contenu  semantique  est  deflni  grace  ^  une 
grille  speciflque. 


L’outil  STATEMATE  (V4.2)  offre  de 
nombreuses  possibilites  et  specificites. 

Le  modeie  activity-charts  statecharts  est 
verifiable  statiquement  (intra  et  inter- 
diagrammes).  D  est  de  plus  verifiable 
dynamiquement  par  exploration  systematique 
(utilisation  des  elements,  atteignabilite, 
impasse,  conflit  competition  ou 

indetetmination). 

0  est  executable  directement  (sans 
instrumentation  suppiementaire)  par 
simulation  :  I'utilisateur  introduit  les  stimuli  et 
en  constate  les  effets  sur  I'animation  graphique 
ou  par  I'examen  des  diverses  informations,  que 
ce  soit  en  interactif  ou  en  batch. 

Les  scenarios  de  test  ou  de  simulation  peuvent 
etre  enregistres,  rcjoues  et  les  traces  des 
resultats  conservees. 

Un  texte  descriptif  pent  etre  associe  ^  tout 
element  et  en  particulier  aux  activites  (ou 
boites)  eiementaires  de  la  decomposition 
(texte,  pseudo-code  ou  formalismc  libre). 
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Le  module  peut  g^n^rer  automatiquement  du 
code  C  ou  Ada;  la  structure  du  code  des 
activitds  dldmentaires  est  prdparde  mais  laissde 
vide. 

Un  panneau  graphique  peut  £tre  ddflni,  lui  6tre 
connect^,  et  son  code  automatiquement 
gdndr6. 

Le  tout  peut  Stre  compild  avec  le  code 
dventuellement  ajoutd  par  I'utilisateur  (dans  les 
activitds  de  base)  et  exdcutd  hors  de 
I'environnement  Stalemate,  constituant  ainsi 
un  prototype  rdaliste  et  interacdf  du  fiitur 
systdme  et  de  son  interface. 

4.2  Prfesntetioo  dw  travaux 

4.2.1.  Moddlisation 

Les  travaux  de  moddlisation  ont  naturelkment 
commencd  par  la  ddfinition  prdcise  de 
I'interface  du  systdme  en  vue  de  moddliser 
I'activity-chart  de  premier  niveau,  figeant  ainsi 
la  nature  et  le  nombre  des  dldments  intervenant 
dans  la  gestion  de  la  logique  opdrationnelle. 

Le  premier  souci  a  6t6  de  mettre  rapidement  en 
oeuvre  une  dbauche  de  moddle  pour  affiner  la 
comprdhension  du  comportement  des  modes 
supdrieurs.  Cette  ddmarche  a  aboud  k 
I'dlaboration  de  plusieurs  moddles  ayant  des 
approches  diffdrentes  du  probldme. 

Trois  moddles  ont  dtd  successivement 
construits.  La  puissance  et  I'ergonomie  de 
STATEMATE  a  grandement  facilitd  le  travail 
de  reprise  des  moddles  (transfert  d'dldments 
d'un  diagramme  ^  I'autre,  gestionnaire  des 
configurations  du  moddle  intdgrd). 

Le  processus  de  validation  statique  du  moddle 
ne  fait  pas  d  proprement  parler  de  la 
moddlisation. 

Toutefois,  dans  la  pratique,  il  est  totalement 
intdgrd  k  la  phase  de  moddlisation  car  les  tests 
de  base  peuvent  gtre  lancds  d  tout  moment 

Ds  sont  particulidrement  utiles  car  ils  viennent 
en  compldment  des  vdrifications  de  cohdrence 
syntaxique  et  sdmantique  effectudes 
automatiquement  lors  de  la  saisie  des 
informations. 

La  vdrification  statique  se  compose  de  tests  de: 

•rectitude :  boucles  de  transitions,  utilisation 
des  informations  conforme  au  type... 


-compldtude  transition  sans  label, 
dvdnement  ddfini  et  non  utilisd... 

4.2.2.  Simulation 

La  moddlisation  dtant  intrinsdquement 
formelle,  le  moddle  est  exdcutable  sans  aucune 
instrumentation  et  dans  la  pratique,  la  phase  de 
simulation  intervient  dds  qu'une  dbauche  de 
moddle  validd  statiquement  est  disponible  (la 
validation  statique  est  facultative  mais 
recommandde). 

La  simulation  interactive  constitue  de  ce  fait 
I'outil  privildgid  de  mise  au  point  du  moddle. 
Dds  qu'une  anomalie  de  fonctionnement  est 
mise  en  dvidence  par  la  simulation,  la 
correction  addquate  peut  etre  apportde  au 
modele. 

Par  un  processus  itdratif,  le  moddle  est 
progressivement  mis  au  point  n  est  d  noter 
que  la  simulation  peut  avoir  pour  objet  un 
sous-ensemble  du  moddle  (dont  la  mise  au 
point  est  particulidrement  ddlicate,  par 
exemple). 

La  simulation  interactive  se  ddroule  pas  k  pas, 
mettant  en  dvidence  les  mdcanismes  mis  en  jeu 
pour  aller  d'un  dtat  d  un  autre. 

II  est  dgalement  possible  d'enchalner 
automatiquement  les  pas  de  simulation  en 
"super-pas"  pour  aller  d'dtat  stable  en  dtat 
stable. 

L'interface  de  la  simulation  interactive  est 
rdalisde  d  I'aide  de  fiches  d  renseigner 
prdsentant  la  liste  des  dvdnements  et  des 
conditions  intervenant  dans  le  moddle. 

STATEMATE  aide  I'opdrateur  en  indiquant 
quelles  informations  peuvent  avoir  une 
incidence  sur  le  moddle  au  prochain  pas  de 
simulation. 

Cette  interface  ne  prdsente  pas  la  convivialitd 
d'une  interface  graphique.  Son  utilisation  est 
lourde,  surtout  pour  la  simulation  d'un  moddle 
complet 

La  simulation  peut  dgalement  etre  utilisde  en 
mode  batch  en  exdcutant  des  fichiers  de 
commandes  gdndrds  manuellement  ou  par  un 
enregistrcment  en  simulation  interactive. 

4.2.3.  Prototvpage 

Le  prototypcur  est  un  outil  dont  la  fonction  est 
de  gdndrer  un  code  (C  ou  ADA)  d  partir  du 
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module  de  specification.  Ce  code  est 
totalement  detachd  de  I’outil  qui  I'a  gdneie  et 
pent  done  6tTe  porte  sur  une  autre  station  de 
travail  depourvue  de  I'outil  STATEMATE. 

La  structure  du  code  des  aedvites  (activity- 
charts)  eiementaires  est  preparee,  I'utilisateur 
peut  eventuellement  y  mettre  un  code 
conespondant  It  la  fonedon. 

Une  opdon  debug  permet  au  prototypeur  de 
creer  on  lien  entre  le  code  gener6  et  les  endt^s 
de  STATEMATE.  les  services  lendus  sont  les 
monies  que  ceux  offerts  par  un  debugger 
classique  (points  d'an€t,  observadon  et 
modificadon  d'endtes  de  STATEMATE, 
traces). 

Enfin,  un  panneau  graphique  d'interface  peut 
etre  connect^  au  code  g^ndrd  par  le 
prototypeur. 

L'ergonomie  et  le  rdalisme  du  prototype  a 
permis  son  exploitadon  par  une  iquipe 
d'ingdnieurs  spdcialistes  du  pilotage 
automadque  des  hdlicopt^res.  Chacun  d'eux  a 
appliqud  les  scenarios  de  tests  qui  lui 
semblaient  pertinents  pour  s'assurer  que  le 
prototype  fonedonne  correctement  et  ainsi 
identifier  rapidement  les  anomalies  du  module. 
Cette  constatation  ddmontre  I'intdrSt  du 
prototypage  comme  instrument  de  validation 
de  la  specification;  il  offre  un  rapport: 
nombre  d’eireurs  d^tecte^temps  de 
detection 

particulierement  eievd. 

4.2.4.  Validation  dvnamique 

La  validation  dynamique  se  presente,  d'une 
certaine  maniere,  comme  le  complement  du 
prototypage  et  de  la  simulation.  EUe  utilise  des 
methodes  systematiques  1^  od  le  prototypage 
fait  appel  ^  I'intuition. 

Elle  rente  de  itipondre  aux  questions  du  type 
"Est-il  possible  que  le  modeie...?"  plutSt  qu'i 
ceUes  du  genre  "(^ue  fait  le  module 
lorsque...?". 

Pour  ce  faire,  I’outil  de  test  dynamique  de 
STATEMATE  possdde  des  mdeanismes 
internes  de  gdn^ration  de  scenarios  de  tests 
alors  qu'en  simulation,  ces  scenarios  sont  bitis 
par  un  opdrateur. 

L'outil  de  test  dynamique  permet  de  tester: 

-  la  non-atteignabilit^  d’6tats  interdits. 

-  I'existence  d'impasse. 

-  la  presence  d'ind6terminismes  du  module. 

-  I’utilisation  des  616ments  du  module. 


-  la  presence  de  confiits  d'affectation  de 
valeurs  k  des  paramitres. 

En  thdorie,  la  puissance  de  cet  outil  est 
sdduisante  et  il  est  tentant  de  I'appliquer  sans 
retenue  au  module  complet. 

Une  tentative  de  verification  complete  des 
regies  d'incompatibilite  des  modes  a  6ti6 
lealisee.  Apres  48  heuies  de  CPU  (sur  SUN 
SPARC  1)  la  verification  n'etait  loujours  pas 
terminee.  D  a  fallu  se  rendie  ^  revidence  que 
ce  genre  d'outil  devait  etie  manipuie  avec 
discemement  si  on  veut  en  tirer  des  lesultats.  n 
est  imperatif,  sur  des  moddles  compliques  de 
limiter  le  champ  d'investigation. 

En  pratique,  il  a  etd  demontre  que  les  etats 
interdits  (par  les  regies  d'incompatibilite)  ne 
pouvaient  etre  atteints  sous  les  hypotheses 
restrictives  suivantes: 

•les  capteurs  demeurent  valides 

•les  trims  sont  embrayds 

•les  directeurs  de  vol  ne  sont  pas  engages. 

Ce  resultat  partiel  a  €\£  obtenu  en  23  heurcs 
CPU. 

Une  demarche  compiementaire  a  consiste  i 
introduiie  sciemment  une  erreur  dans  le 
modeie  (une  transition  incorrecte  conduisant  4 
une  combinaison  de  modes  interdite)  et  ^ 
verifier  que  l'outil  etait  capable  de  la  retrouver. 
La  detection  a  pris  8  minutes  CPU.  le  scenario 
trouve  par  l'outil  a  ete  verifie  a  posteriori  en 
simulation  interactive. 

La  validation  dynamique  possede  done  des 
atouts  qu'il  serait  dommage  de  ne  pas 
exploiter. 

D  est  raisonnable  de  penser  qu'en  prenant 
certaines  precautions  dans  la  conception  du 
modeie,  la  validation  dynamique  puisse  etre 
facilitee  (cette  contrainte  n'a  pas  ete  prise  en 
compte  dans  notre  modeie). 

L'accroissement  probable  de  la  puissance  CPU 
dans  les  annees  futures  milite  egalement  en 
faveur  de  I'approche  "tests  dynamiques". 

4.3  Apports  de  la  methode 

La  methode  de  HAREL  prdsente  une  grande 
homogeneite  au  niveau  des  concepts 
manipuies; 

les  statecharts,  originalite  de  la  methode, 
s'integrent  naturellement  aux  activity-charts 
pour  obtenir  une  approche  tres  visuelle  du 
probieme  de  la  specification. 
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Les  [Mrincipes  mis  en  oeuvre,  s'ils  sont 
novateurs.  s'appuient  sur  des  notions 
largement  r^pandues  dans  I'industrie 
(diagrammes  6tats/transitions,  diagrammes  de 
hots  de  donn^es).  Ils  permettent  n6anmoins  de 
construire  une  sp^ificadon  formelle  du 
syst&me. 

La  m^thode  de  HAREL  est  suppoit6e  par 
I'oudl  STATEMATE  qui  permet  de  tirer  profit 
de  ia  puissance  de  la  m^thode. 

STATEMATE,  outre  ses  fonctions  d'6didon  et 
de  verification  statique  des  elements  de  la 
specification,  permet  d'executer  le  modeie  de 
specification. 

L'interet  de  la  simulation  n'e.:it  plus  4 
demontrer;  pour  les  systimes  complexes, 
i'obtention  d'uiie  spedllcation  coherente  et 
validee  impose  quasiment  d'y  avoir  recours. 

STATEMATE  offre  une  panoplie  d'outils 
integres  qui  ont  pu  etre  appitfcies  au  cours  de 
retude: 

-  une  base  de  donnees  (gerant  les  elements  de 
la  specification)  autour  de  laquelle  s'articulent 
des  utilitaires  d’interrogation  et  de  gestion  de 
configuration. 

-  un  prototypeur  generant  un  code  detache  de 
I'outil  et  done  portable. 

-  un  outil  de  validation  dynamique  generant 
automatiquement  des  scenarios  de  test 

Des  ameliorations  de  STATEMATE  sont 
attendues : 

-correction  des  erreurs  du  prototypeur. 
-connexions  de  panneaux  d'interfaces 
graphiques  ^  la  simulation,  en  vtie  de  la  doter 
d'une  bonne  ergonomie. 

STATEMATE  s'est  reveie  etre 
particulierement  bien  adapte  ^  la  specification 
de  la  logique  d'engagement  des  modes 
superieurs. 

Lots  de  cette  etude,  les  limites  de  la  methode 
et  de  I'outil  ne  sont  pas  apparues  (sauf  peut- 
etre  au  itiveau  de  la  validation  dynamique).  D 
est  done  permis  de  penser  que  la  methode  de 
HAREL  et  STATEMATE  sont  bien  adaptds  ^ 
la  specification  du  comportement  des  systSmes 
tels  que  les  pilotes  automatiques  d'heiicoptere. 

5.  Evaluation  de  G2 


S.l  Rapod  sur  la  methode 

La  n^thode  supportee  par  G2  s'articule  autour 
de  la  constitution  d'une  base  de  connaissiuices 
construite  4 1'aide  de  I'outil  G2. 

Une  base  de  connaissances  est  principalement 
constituec : 

-d'objets 

-de  tables  d'attributs,  qui  permettent  de 
decrire  les  caracteristiques  de  chacun  des 
objets. 

-de  classes  d'objets  organisees  suivant  une 
structure  hierarchique. 

-de  variables  et  de  paramdtres  :  objets  dont 
les  valeurs  sont  des  nombres,  des  syraboles 
ou  du  texte. 

-de  connexions  et  de  relations  qui 
reprfsentent  les  relations  physiques, 
logiques  ou  temporelles  existant  entre  les 
Aliments  de  la  base  de  connaissances. 

-de  regies  qui  d^finissent  le  comportement 
du  syst^me 

-de  procedures  :  ensemble  de  commandes  du 
langage  procedural  de  G2. 

-de  fonctions  permettant  d'effectuer  des 
operations  arithmetiques. 

La  specification  se  presente  comme  une 
modeiisation  du  systdme,  realisde  ^  base 
d'objets  et  de  rtgles. 

Les  objets  dderivent  les  elements  de  la 
specification  d'ordre  structurel.  Tout  objet  est 
une  instanciation  de  classe. 

Les  classes  d'objets  sont  organisees  de  maniere 
hierarchique  de  fa^on  ^  ce  que  les  sous-classes 
puissent  heriter  des  attributs  des  classes 
superieures  auxquelles  elles  appartiennent. 
R^iproquement,  la  hierarchisation  des  classes 
permet  de  definir  les  attributs  communs  k 
plusieurs  objets  au  niveau  de  la  classe 
superieure  H  laquelle  les  objets  en  question 
appartiennent. 

Les  regies  decrivent  I'aspect  comportemental 
du  modeie.  Elles  renferment  en  fait  la 
connaissance  de  I'expert,  dans  la  mesure  oh 
elles  determinent  comment  le  modeie  doit 
rdpondre  aux  diverses  sollicitations. 
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Elies  opirent  essentielkment  sur  les  iUtributs 
des  objets  et  peuvent  done,  de  ce  fait,  €tre 
gdndriques. 


Une  rbgle  est  compost  de  deux  parties  : 

-I'antdc^dent,  qui  d^crit  les  condidoiis 
d'acdvation  de  la  r^gle. 

-la  cons^uence,  qui  d6crit  ce  qui  est 
effectu^  lorsque  la  ligle  est  aedv^. 

Un  moteur  d'inffrence  permet  I'invocadon  des 
regies  suivants  difffrents  m^anismes  ; 

-Chainage  avant:  la  rdgle  est  invoqu^  lorsque 
les  parambtres  figurant  dans  I'antdcddent 
refoivent  une  nouvelle  valeur. 

-Chainage  arribre:  une  rigle  R1  est  invoqude 
lorsque  sa  consequence  o[^re  sur  un  parametre 
dont  te  moteur  d'infdrence  a  bewin  pour 
dvaluer  rantdeddent  d'une  rdgle  R2  qu'il  doit 
invoquer. 

-Invocadon  de  rdgles  par  catdgorie. 

-Invocadon  pdriodique  de  rdgles. 

-Invocadon  des  tdgles  assocides  k  un  objet 
paidculier. 

Ce  moteur  d'infdrence  est  dit  "temps  rdel",  ce 
qui  signifie  en  fait  qu'un  temps  de  rdponse  de 
Tordre  de  la  seconde  est  garand. 

L'oudl  G2  est  disponible  sur  la  plupart  des 
stadons  de  travail  du  marchd 

S.2  Presentation  des  travaux 

5.2. 1.  Moddlisadon 

La  phase  d'analyse  a  conduit  k  I'idendflcadon 
des  principes  gdndraux  gdrant  les  modes 
supdrkurs  et  en  pardculier  la  nodon  de 
compadbilitd  entre  modes. 

Ces  principes  peuvent  dtre  ddcrits  par  un 
nombre  limitd  de  rdgles  de  comportement 

La  moddlisadon  "objet”  est  rdalisde  ^  partir 
des  divers  dldments  de  spdcificadon 
intervenant  dans  les  idgles  de  comportement: 
les  axes  de  pilotage,  les  d^teurs  de  vol,  les 
modes  supdrieurs  et  le  sdlecteur  de  navigadon. 


Les  classes  d'objets  ont  done  dtd  dddnies  et 
hidrarchisdes 

A  chacun  de  ces  objets  ont  dtd  associds  des 
attributs  et  les  valeurs  de  ces  attributs 
ddfinissent  les  modes  dont  les 
engagement/armement  sont  autorisds  sur  I'axe. 

Les  diffdrents  modes  supdrieurs  sont  des 
instances  d'une  de  ces  classes.  La  nature  et  le 
nombre  de  leurs  attributs  sont  fonedon  de  la 
classe  ^  laquelle  ils  appartiennent,  ce  qui 
ddfinit  en  fait  un  type  de  comportement 

La  reprdsentadon  "objet”  rdsout 
intrinsdquement  une  partie  du  probldme  de  la 
vdrificadon  dans  la  mesure  od  ebaque  objet 
respects  le  formalisme  de  la  classe  ^  laqueUe  il 
appardent  ce  qui  garandt  un  premier  niveau 
de  cohdrence. 

L’dcriture  des  rdgles  servant  k  moddliscr  le 
comportement  du  systdme,  intervient 
logiquement  aprds  la  erdadon  des  objets.  Un 
certain  nombre  de  variables  (validiuis,  dtat 
trim,  captures)  compldtent  la  reprdsentadon 
objet  Une  teladon  incompatible  est  udlisde 
pour  aider  k  dderire  les  incompadbUitds  entre 
modes. 

Comme  excmple  de  rdglc  gdndriquc  opdrant 
sur  une  classe,  on  peut  pidsenter  la  rd^e  qui 
ddsengage  les  modes  aedfs  k  I'engagement 
d'un  mode  incompadble. 


whenever  the  etat  of  any  mode  m  receives  a 
value 

and  when  the  etat  of  m  is  actif 
and  the  etat  of  any  mode  m2  that  is 
incompatible  m  is  actif 

then  conclude  that  the  etat  of  m2  is  inactif 


Cette  rdgle  fait  intervenir  explicitement : 

-  la  classe  mode  et  son  attribut  etat  avec  ses 
valeurs  actif  et  inactif 

-  la  teladon  incompatible 

Cette  rdgle,  trds  gdndrique,  s'appliquc  pour 
chaque  instance  de  la  classe  mode. 

Cet  exemple  donne  une  idde  de  la  lisibilitd  des 
rdgles.  Les  endtds  erddes  pour  les  besoins  de  la 
moddlisadon  portent  des  noms  fran^ais. 
L'udlisadon  de  termes  anglais  conjugude  ^  un 
choix  judicieux  (jncompatible-with  au  lieu  de 
incompatible)  aurait  permis  d'obtenir  une 


fonDuladon  des  regies  proche  du  langage 
natuitl  (de  I'anglais!). 

Le  moteur  d'infdrence  de  G2  est  dot£  de 
nombreuses  possibilitds  d'invocation  de  rtgle; 
seuls  les  cha&oage  avant  et  airiiie  ont  6t6 
udlisds  pour  chaque  r^gle. 

Remarque 

Une  iimitadon  de  la  mdthode  lide  i  i'utiliaatioa 
de  I'outil  G2  apparait  It  ce  stade  des  travaux. 
L'ensemble  des  modes  supdrieuis  a  6t£ 
pardtionnd  en  un  ensemble  de  classes.  Chaque 
mode  appardent  done  k  une  classe  et  une 
seule.  Comrae  une  classe  ddfinit  un  type  de 
comportement,  il  est  done  ndcessaiie  de 
rdaliser  une  parddon  fine  de  l'ensemble  des 
modes  pour  traduiie  la  diversity  des 
comportements.  Le  nombre  d'instances  d'une 
classe  terminale  se  trouve  de  ce  fait  bien 
souvent  rdduit  ^  un  ou  deux. 

Dans  ce  type  d'approche,  seule  la 
hidrarchisadon  des  classes  peimet  une 
rdduedon  de  la  compl  'xitd  par  une  fdddradon 
des  comportements  dldmentaiies. 

Une  approche  permettant  de  construiie 
plusieurs  parddons  de  I'ensembles  des  modes 
aurait  perrais  d'obtenir  des  classes  de  cardinal 
plus  dlevd. 

Chaque  mode  aurait  alors  appartenu 
simidtandment  k  plusieurs  classes  d'objets, 
chacune  d'entre  elles  refldtant  une  facette  de 
son  comportement 

Cette  approche  aurait  ndcessitd  I'udlisadon  de 
la  nodon  d'hdritage  muldple,  que  I'oudl  G2  ne 
possdde  pas. 

5.2.2.  Simuladon 

Le  module  obtenu  est  exdcutable,  il  se  prete 
done  k  la  simuladon. 

L'dtape  suivante  des  travaux  a  consistd  en  la 
rdalisadon  d'une  interface  de  simuladon. 

Une  moddlisadon  graphique  des  61dments 
intervenant  dans  cette  interface  a  €t£ 
consdtude.  Cette  interface  a  6t6  r^alisde  sans 
veritable  soucis  d'obtenir  une  ergonomie 
voisine  de  celle  du  syst&me  r^l.  Sa  fonedon 
est  uniquement  I’alimentadon  du  module  en 
donndes  et  la  visualisadon  des  6tats  obtenus. 
Sa  construedon  a  largement  fait  ^pel  aux 
composants  d'interface  disponibles  dans  les 
libraiiies  compldmentaires  de  G2  (objets 
graphiques  permettant  de  lancer  des  acdons 
G2,  d'affecter  des  valeurs  k  des  variables 
symboliques...). 


Les  simuladons  "en  batch"  avec  ex6cudon 
automadque  d'un  flchier  de  commandes- 
op^rateurs  datdes,  sont  fgalement  possibles. 

La  simuladon  s'exdcute  alors  suivant  le 
sdqueiK^ement  ddcrit  dans  le  flchier  de 
commandes;  les  6tats  du  module  sont 
enregistrds  dans  un  fichier  de  traces  et  sont 
simultandment  visualises  sur  I'interface  de 
simuladon. 

Les  simuladons  interaedves  et  batch  utilisent 
(ks  concepts  voisins  et  sont  fortement 
inkgrees.  La  simuladon  interaedve  peut  etre 
udUsde  pour  gdnerer  le  fichier  de  commandes 
de  la  simuladon  batch  (par  enregistrement  dak 
des  commandes);  les  dchiers  de  r^sultats  sont 
rdalisds  par  le  meme  udlitaire. 

La  phase  de  simuladon  est  nature  ih  inent 
fortement  coupiee  avec  la  phase  de 
moddlisadon. 

La  mise  au  point  du  module  est  un  processus 
rdcurent;  la  simuladon  permet  de  confronter  le 
module  ^  la  spdcificadon  textuelle,  de 
diagnosdquer  rapidement  les  erreurs  par  des 
simuladons  interaedves. 

5.2.3.  Validation 

Les  coatrdles  internes  k  G2  assurent  la 
coherence  syntaxique  du  module  et  permettent 
d'dviter  la  phase  de  vaUdadon  stadque. 

La  validation  du  module  consiste  done  en  une 
validation  dynamique  r6alis6e  avec 
I'environnement  de  simulation. 

La  mesuie  de  la  couverture  du  module  est 
r6alis6e  k  I'aide  d'un  udUtaiie  marquant  les 
situations  rencontrfes  au  cours  des  simuladons 
batch. 

En  pratique  il  a  6t6  possible  de  r^aliser  la 
couverture  des  points  suivants  de  la 
specification : 

-atteignabilik  des  ftats  d'engagement 
(d'armement  le  cas  6cheant)  en  couplage  et 
en  directeur  de  vol  pour  chacun  des  modes, 
•atteignabilitf  de  chacun  des  etats  syskmes. 
-verification  que  les  etats  syskmes  non 
permis  (modes  incompadbles)  ne  sont  pas 
rencontres  lors  des  simuladons. 

Cet  udlitaire  foumit  la  metrique  necessaire  4  la 
construction  des  fichiers  de  simuladon  batch 
qui  constituent  les  tests  de  couverture  du 
modeie.  La  construedon  de  ces  fichiers  peut 


£tre  effect!!^  soil  pv  une  simulation 
interactive,  soit  par  une  Edition  directe. 

Cette  couverture  est  relativement  limitfe;  si 
I'approche  objet  retenue  intdgre  la  notion  d'6tat 
sys^me,  elle  ne  formalise  pas  celle  de 
transition  d'etat  Le  changement  d'6tat  est 
effectu£  par  Vintermddiaiie  des  rbgles  de 
comportement. 

La  couveiture  des  transitions  d'dtat  ne  peut 
done  pas  £tre  effectu6e  avec  le  formaliane  du 
module. 

Pour  pallier  ce  manque,  I'approche  adoptfe  a 
consist^  h.  g^ndrer  automatiquement  un 
automate  k  6tats  finis  k  partir  du  module. 

La  simulation  est  udlisde  pour  g^ndrer  les 
transitions  entre  dtats;  pour  chacun  des  6tats  du 
syst^me,  toutes  les  actions  possibles  sur  les 
dements  de  I'interface  sont  simul6es;  les 
transitions  vers  les  ^tats  systime  atteints  sont 
alors  erodes. 

Pour  obtenir  un  jeu  de  tests  exhaustif,  il  reste  4 
parcourir  I'automate  en  passant  par  toutes  les 
transitions  d'etat 

L'algorithme  retenu  est  dldmentaire:  A  partir 
d'un  6tat  initial,  une  transition  non  parcourue 
est  fianchie,  ce  processus  se  rdpdte  jusqu'^  ce 
qu'une  impasse  soit  atteinte  (une  impasse  pour 
cet  algorithme  est  un  6tat  au  ddpart  duquel 
toutes  les  transitions  ont  6ti6  parcourues),  ce 
parcours  correspond  k  un  test 

Un  nouvel  6tat  initial  est  ensuite  choisi  parmi 
les  6tats  possddant  encore  des  transitions 
sortantes  non  parcourues. 

Le  processus  d^crit  plus  haut  est  leconduit 
L'algorithme  est  arret^  lorsque,  pour  chaque 
^tat,  toutes  les  transitions  sortantes  sont 
parcourues. 

Cette  approche  a  6t6  maquettde  en  limitant  le 
vecteur  d'6tat  du  systdme  aux  modes  engages 
(pas  d'aimement  de  mode),  en  limitant 
I'interface  aux  boutons  d'engagement  des 
modes  et  avec  le  sdlecteur  de  navigation  dans 
la  seule  position  NAV. 

L'automate  obtenu  ne  comporte  que  26  6tats  et 
260  transitions  et  le  nombre  de  tests  assurant 
la  couverture  est  de  30. 

Les  6tudes  sur  la  g6n6ration  automatique  de 
tests  ont  d6montr6  la  faisabilitd  de  I'approche 
automate  ^  6tats  finis  pour  valider  le  mod&le. 


L'application  de  cette  mdthode  au  module 
complet  risque  cependant  d'en  r6v61er  les 
limites,  notamment  lorsque  le  nombre  de 
composantes  du  vectem  d'6tat  s'accroit  (modes 
aimds,  directeur  de  vol)  et  que  tous  les 
616ments  de  I'interface  du  module  sont  pris  en 
compte. 

5.2.4.0ptimisation  du  module 

Le  module  pr6sent6  dans  le  chapitre  pr6c6dant 
poss^de  une  structure  voisine  de  celle  du 
document  de  specification  textuel  qui  a  servi 
de  base  ^  la  modeiisation.  Les  aspects 
comportementaux  du  pilote  automatique  sont 
decrits  fonction  par  fonction. 

La  demarche  qui  a  prevalu  lots  de  la  redaction 
des  fugles  de  comportements,  a  consiste  ^ 
priviiegier  le  caractere  systematique  au  depend 
de  la  ginericite. 

Les  principes  gfneraux  legissant  le 
comportement  des  modes  transparaissent 
pourtant  au  travers  de  I'aspect  systematique  de 
certaines  rdgles.  C'est  ^  ce  niveau  que  se  situe 
veritablement  I’expertise  et  c'est  cette  approche 
que  Ton  a  tente  de  promouvoir  en  teprenant  le 
modeie. 

L’objectif  est  d'obtenir  un  moddle  concis, 
constitue  de  ingles  que  les  modes  doivent 
suivre  plutdt  que  de  regies  formalisant  le 
comportement  de  chacun  modes. 

Le  travail  de  reprise  du  modeie  a  consiste  ^ 
reptendre  les  regies  groupe  par  groupe. 

L'editeur  syntaxique  de  regies  s'est  revile  etre 
bien  adapts  k  une  utilisation  par  des  personnes 
peu  rompues  ^  la  semantique  du  langage.  Son 
ergonomie  a  6x6  particulierement  appr&iec;  il 
propose  i  chaque  caractere  saisi  la  liste  des 
mots  autorises,  verifie  en  ligne  la  coherence  de 
la  regie  editee.  L'editeur  autorise  I'existence 
d'etats  inteimediaires  syntaxiquement 
incoherents,  I'interet  pratique  de  cette  facilite 
est  evident  lors  d'une  modification  de  regie. 

A  chaque  etape  de  la  modiftcation  du  modeie, 
le  recours  systematique  k  la  simulation  a 
permis  de  s'assurer  que  le  comportement  du 
modeie  demeurait  inchange. 

Le  nouveau  modeie  a  beaucoup  gagnd  en 
genericite,  en  concision  et  en  Usibilite.  La 
maintenabilite  du  modeie  a  progresse. 


A  title  d'exemple,  I'adjonction  d'un  nouveau 
mode  de  pilotage  se  limiterait  4  la  creation 
d'un  nouvel  objet  par  mstanciadon  de  la  classe 
auquel  le  nouveau  mode  appaitiendrait  et  au 
renseignement  de  quelques  attributs  (sous 
reserve  que  ce  nouveau  mode  ait  un 
comportement  apparent^  4  un  comportement 
d6j4  rencontrd). 

La  d^raa.  ‘.e  adoptee  dans  cette  phase  des 
travaux,  pourrait  certainement  etre  encore 
poursuivie.  Des  gains  en  mad4re  de  lisibidtd 
des  ligles  pourraient  facilement  etre  obtenus 
par  un  choix  plus  addquat  des  noms  d'attributs, 
de  relations  et  de  procddures. 

Toutefois,  les  limites  de  G2  en  mati4re 
d'h^ritage  multiple  (ddcrites  dans  le 
paragraphe  pr^c^dant)  se  sont  fait  fortement 
ressentir  et  constituent  I'obstacle  principal  au 
gain  d'un  ordie  de  grandeur  en  mati^re  de 
gdndricitd  du  module. 

5.3  Apports  de  la  methode 

La  mdthode  basde  sur  G2  s'articule  autour  des 
notion  de  representation  objet  et  de  syst4me 
expert. 

Ces  techniques  sont  tr^s  novatrices,  surtout 
dans  le  domaine  Je  la  specification.  Leur 
utilisation  combinee  a  conduit  4  I'obtention  de 
resultats  satisfaisants;  la  gestion  de  la  logique 
d'engagement  des  mod^  superieurs  et  la 
visualisation  associee  ont  pu  etre  modeiisees  4 
I'aide  de  la  methode. 

Le  modeie  obtenu  est  executable  et  son 
interface  graphique  possdde  de  reelles  qualites 
d'ergonomie  qui  rendent  son  exploitation  aisee 
par  des  opdrateurs  n'ayant  aucune 
connaissance  des  techiuques  informatiques 
mises  en  oeuvre  pour  construire  le  module. 

Cette  qualite  pourrait  6tre  avantageusement 
mise  4  profit  pour  constituer  les  scenarios  de 
validation. 

La  maintenabilite  du  module  obtenu  est  bonne. 
De  plus,  la  formation  tequise  pour  effectuer  la 
maintenance  est  beaucoup  plus  reduite  que  le 
caractere  novateur  des  techniques  utilisees 
aurait  pu  le  laisser  supposer. 

L'approche  "objet”  est  en  fait  assez  intuitive, 
rediteur  de  regies  de  G2  allie  la  puissance  au 
caractere  did^tique.  La  preuve  en  a  ete 
donnee  par  I'usage:  des  modifications 


importantes  du  modeie  ont  pu  etre  realisees 
rapidement  avec  un  taux  d'erreurs  tres  faible. 

L'apport  de  la  methode  dans  la  phase  de 
sp&nfication  est  demontre.  toutefois  il  est 
d^ficile  d'envisager  une  extension  importante 
de  son  champ  d'operation  en  dehors  des 
aspects  gestion  de  la  logique  operationnelle. 

La  methode  basde  sur  G2  apparait  plutot 
comme  une  methode  de  prototypage 
particulierement  rapide  de  I'aspect 
comportemental  des  syst^mes. 

L'envirormement  de  simulation  permet  la 
validation  de  la  maquette  et  les  scenarios  de 
tests  de  validation  sont  reutilisables  en  phase 
de  validation  du  syst^me  reel. 

La  puissance  de  l'approche  orientee  objet  a  ete 
appreciee  et  fait  d'autant  plus  regretter 
I'absence  de  la  notion  d’heritage  multiple  qui 
aurait  permis  4  la  methode  de  gagner  en 
concision  et  rapidite  de  construction  du 
modeie. 


6.  Conclusions 

Ces  techniques  ont  permis  de  construire  dcs 
specifications  et  de  les  valider  avec  des  degres 
de  compietude  plus  ou  moins  importants. 

L'interSt  de  ces  techniques  a  ete  clairement 
demontre  et  elles  apparaissent  comme  des 
eiements-cies  dans  une  demarche  organisee  de 
reduction  du  cout  de  developpcment  des 
logiciels  des  syst^mes  complexes. 

n  reste  desormais  4  montrer  qu'une 
specification  peut  etre  entierement  formalisee 
par  I'utilisation  d'une  methode  de  description 
des  aspects  comportementaux  coupiee  4  une 
methode  de  description  des  aspects 
transformationnels,  et  que  ce  couplage  est 
industriellement  utilisable  et  benefique. 

La  mise  en  pratique  sur  un  projet  d'envergure 
nous  permettra  de  confirmer  le  bien  fonde  de 
nos  suppositions  sur  la  maitrise  des  couts  et 
d'observer  les  reactions  de  nos  clients  vis-4-vis 
de  ces  nouvelles  fagons  de  travailler. 

Dej4  la  definition  d'une  methodologie 
integrant  ces  nouvelles  techniques  est 
envisagee  et  celle-ci  sera  presentee  aux 
Services  Officiels  pour  obtenir  leur  avis  quand 
a  son  application  dans  les  syst^mes  developpes 
pour  Faeronautique,  tant  civile  que  militaire. 
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1.  SUMMARY 

The  design  of  the  optimal  strategy 
for  decision  making  is  intractably 
difficult  when  information  sources 
(sensors)  provide  different  amounts 
of  information  and  have  different 
costs  associated  with  their  use. 
This  paper  describes  a  sub-optimal 
design  algorithm  wh...:h  can  be 
further  simplified  if  the  user 
specifies  some  parts  of  the  decision 
process  to  be  executed  at  run-time. 
The  design  algorithm  is  provided 
with  diagnostics  so  that  the  result 
can  be  compared  with  accuracy  and 
response  time  requirements,  and  a 
learning  module  which  enables  new 
information  to  be  incorporated  into 
the  knowledge  base.  The  complexity 
of  this  algorithm  is  compared  to 
that  of  the  optimal  design 
algorithm. 

2.  INTROOUCTIOH 

There  are  many  interesting 
applications  for  real-time  Decision 
Making  Processes  (DMP's).  Examples 
are  Electronic  Support  Measures 
(E5M)  logic  design.  Electronic 
Countermeasures  (ECM)  optimization. 
Indications  and  Warning  logic  design 
and  fault  isolation/diagnosis 
strategy  in  avionics.  DMP's  must  do 
the  following: 

o  Apply  a  set  of  sensors  to 
determine  the  characteristics 
of  an  object  in  the  environment. 
(In  this  context,  a  ’‘sensor”  is 
any  instrument  which  observes  an 
object  and  reports  the  value  of 
an  attribute.  The  instrument 
could  be,  for  example,  an 
interferometric  frequency 
measurement  device  or  a  human 
being  counting  objects  in  the 
environment. ) 


o  Compare  the  sensor  readings  to  a 
knowledge  base 

o  Provide  an  identification  or 
classification  of  the  object 
despite  residual  uncertainty 

...subject  to  response  time  and 
probability  of  error  constraints.  The 
task  is  made  more  difficult  by  the 
fact  that  the  sensors  have  varying 
penalties  associated  with  their  use. 
For  example,  it  may  take  much  longer 
for  a  Radar  Warning  Receiver  (RWR)  to 
determine  the  scan  rate  of  a  radar 
than  to  determine  the  pulse  recurrence 
interval.  The  difference  in  response 
time  could  mean  an  unacceptable  delay 
in  the  initiation  of  countermeasures 
against  the  radar.  It  is  therefore 
important,  to  select  an  efficient 
strategy  for  the  order  in  which 
parameters  are  considered  to  obtain 
the  maximum  information  with  the  least 
cost. 

Finding  the  optimal  DMP  strategy 
however,  is  a  Non-Deterministic, 
Polynomial  time  (NP),  complete  task. 
(1)  This  means  that  the  algorithm  to 
solve  the  problem  may  be  simple  to 
write,  but  not  feasible  to  run  because 
of  the  great  computational 
requirements.  It  is  necessary 

therefore,  to  accept  a  sub-optimal, 
but  "good  enough",  result.  Moreover, 
the  control  structure  c:  any  logically 
correct,  run-time  procedure  is  so 
complex  that  standard  methods  of 
structured  analysis  for  software 
design  are  not  applicable.  The  result 
is  that  DMP's  may  be  designed  in  an 
unstructured  way  and  that  performance 
(response  time  and/or  confidence) 
requirements  can  be  exceptionally 
difficult  to  satisfy. 
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A  ralatad,  potential  difficulty  ia 
caused  by  the  fact  that  the 
knowledge  base  for  a  DMP  ie  subject 
to  change.  For  example,  a  new  sensor 
could  be  installed  in  a  part  of  the 
spectrum  not  covered  before  and  its 
contribution  to  situation  assessinent 
must  be  taken  into  account.  If  the 
original  OMP  design  was  produced  by 
unstructured  methods,  the  update 
task  can  be  as  difficult  as  the 
original  design  task. 

The  task  of  specifying  a  DMP  and  the 
possibility  of  developing  CASE  tools 
for  design  is  discussed  by  Borden 
and  Cinar  in  Reference  2.  The 
implications  for  NP-Completenesa  of 
Radar  Warning  Receiver  (RWR)  design 
are  discussed  in  Reference  3. 

The  purpose  of  this  paper  is  to 
describe  an  algorithm  which  can  be 
used  to  design  an  efficient  decision 
making  strategy  for  a  real-time  DMP. 
The  procedure  to  be  described  is  a 
greedy  algorithm  which  selects  the 
sensor  providing  the  greatest  ratio 
of  new  information  to  cost  at  each 
node  of  the  decision  tree,  it  will 
not  however,  guarantee  a  globally 
optimised  decision  strategy. 

3.  RBLATBO  RESULTS 

Goodman  and  Smyth  (4)  describe  an 
information  theoretic  algorithm  used 
to  build  decision  trees.  There  are 
two  important  differences  between 
the  Goodman/Smyth  Algorithm  (GSA) 
and  the  algorithm  described  in  this 
paper  (OMP  Designer) : 

o  The  GSA  assumes  that  every  sensor 
has  the  same  cost  whereas,  the 
OMP  Designer  assigns  different 
costs  (response  times)  to 
different  sensors. 

o  The  GSA  selects  a  new  sensor  to 
expand  a  node  based  on 
the  amount  of  mutual  information 
between  the  new  sensor  and  the 
environment.  The  DMP  Designer 
selects  a  new  sensor  based  on  the 
reduction  in  conditional  entropy 
at  each  node,  taking  into  account 
the  information  that  other 


sensors  have  already  provided. 
Unless  the  overlap  in  sensor 
readings  for  different  objects  in 
the  enviroiunent  is  very  uniform, 
the  DMP  Designer  will  alsiost 
certainly  provide  a  different  and 
more  efficient  result. 

Goodman  and  Smyth  do  not  discuss 
diagnostics  which  could  be  made 
available  to  the  user.  However,  they 
do  describe  a  learning  module  which 
can  compute  statistics  from 
observations  of  a  new  object  and 
update  the  knowledge  base  accordingly. 
This  learning  module  has  been  adapted 
for  use  in  the  DMP  Designer. 

4.  DESCRIPTION  OF  THE  ALGORITHM 
The  inputs  to  the  procedure  include  a 
description  of  the  sensor  suite: 
o  The  number  of  sensors 

o  The  response  time  (or  other  cost) 
of  each  of  the  sensors 

o  A  partition  of  the  set  of  possible 
readings  for  each  sensor  ( j )  into 
“windows"  (k)  or  discrete  values 

The  user  also  provides  a  knowledge 
base  which  includes  the  a  priori 
probability  of  occurrence  of  an  object 
of  type  i  (O^)  in  the  environment  and 
the  conditional  probability  that  the 
sensor  j  will  report  a  value  in  window 
k  when  observing  an  object  of  type  i: 
P(W,klOi). 

Finally,  the  user  provides  a  stopping 
rule  to  ensure  that  a  branch  of  the 
decision  tree  terminates  when  the 
probability  of  an  incorrect 
classification  is  small  enough. 

The  first  step  in  the  algorithm  is  to 
find  a  branch  of  the  current  decision 
tree  which  does  not  have  a  terminal 
indicator.  The  existing  tree  could  be 
the  root  node  if  the  tree  is  being 
built  from  scratch,  a  branch  of  a 
partial  tree  provided  by  the  user  or  a 
branch  of  the  tree  as  it  has  been 
constructed  by  the  algorithm  thusfar. 
If  every  branch  has  a  terminal 
indicator,  the  algorithm  prints  the 
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complatcd  trM  and  th«  user  may 
procamd  to  tha  diagnostica  modula. 

One*  tha  branch  haa  baan  aalactad, 
tha  aanaora  not  yat  uaad  on  that 
branch  ara  ratriavad.  If  tha  number 
of  aanaora  already  uaad  aquala  tha 
total  number  of  aanaora,  a  failure 
notification  ia  appended  to  tha 
branch  and  tha  algorithm  goaa  back 
to  atep  one  to  find  another  branch. 
Otharwiaa,  tha  available  aenaor 
providing  tha  maximum  payoff  in  bita 
of  independent  information  per 
aecond  ia  aalected.  Tha  node  at  the 
end  of  the  branch  is  expanded  for 
all  possible  (discretized)  attribute 
values  which  the  new  sensor  might 
provide. 

Finally,  the  algorithm  tests  all  the 
new  nodes  which  have  been  generated. 
If  the  stopping  rule  is  met,  a 
terminal  indicator  ia  appended  in 
the  form  of  a  positive 
classification  result.  When  this 
activity  is  completed,  the  algorithm 
returns  to  the  first  step. 

The  diagnostics  module  reports  the 
confidence  level  for  every  positive 
classification,  the  a  priori 
probability  of  every  branch  of  the 
tree  which  terminates  in  failure, 
the  latency  time  for  every  branch  of 
the  tree,  the  mean  latency  time  and 
the  expected  throughput  in  bits  per 
second.  To  correct  classification 
failures  which  have  a  significant 
probability  of  occurrence,  the  user 
can  specify  a  result  and  annotate 
the  branch  appropriately.  If  the 
latency  time  on  any  branch  is 
unsatisfactory,  he  may  terminate  the 
branch  earlier  and  and  specify  a 
result.  After  editing,  the  user  may 
re-run  the  diagnostics  to  determine 
the  performance  of  the  modified 
tree. 

This  algorithm  does  not  solve  the 
NP-complete,  global  optimization 
problem.  The  problem  it  does  solve 
however,  is  still  very  complex  if 
the  problem  domain  is  large,  i.e.  if 
there  are  many  different  object 
types  in  the  environment,  many 


sensors  and  many  windows  for  each 
sensor.  To  reduce  the  complexity  of 
the  design  task,  the  user  can  specify 
a  partial  tree  in  advance.  In  this 
way,  the  user  can  circumscribe  the 
work  to  be  done  by  the  algorithm  and 
reduce  its  complexity.  If  the  user 
places  a  terminal  indicator  on  any 
branch,  the  algorithm  will  ignore  all 
possible  expansions  at  this  node  and 
work  on  the  remainder  of  the  tree. 
The  ability  of  tha  user  to  specify 
part  of  the  solution  is  especially 
useful  if  a  change  to  the  knowledge 
base  occurs  which  affects  only  part  of 
the  existing  decision  tree. 

Typically,  the  first  sensor  to  be 
consulted  is  pre-determined  either 
because  it  is  a  direct  output  of  pre¬ 
processing  or  because  it  is  an  alarm 
which  initiates  the  decision  making 
activity.  It  is  not  necessary 
however,  to  specify  any  part  of  the 
decision  tree  in  advance. 

The  learning  module  adapted  from  the 
GSA  can  be  used  to  add  to  the 
knowledge  base  by  statistical  analysis 
of  a  sample  data  set  derived  from  a 
new  object  in  the  environment.  It 
could  (for  example)  add  the  parameters 
of  a  new  radar  emitter  or  wartime  mode 
to  the  knowledge  base  used  by  an  ESM 
system.  This  module  automatically 
computes  the  statistics  of  the 
parameter  distributions,  adds  them  to 
the  knowledge  base  and  redesigns  the 
decision  tree  as  required.  It  is 
necessary  however,  for  the  user  to 
provide  the  a  priori  probability  of 
occurrence  of  the  new  object. 

5.  INFORMATION  THEORETIC 
CONSIDERATIONS 

The  fundamental  consideration  in 
designing  this  algorithm  is  to  obtain 
the  maximum  amount  of  mutual 
information  between  the  selected 
sensors  and  the  domain  with  the  least 
cost  (usually  time).  At  each  node  of 
the  decision  tree,  the  maximum  payoff 
sensor  (in  terms  of  bits  of  new 
information  per  second)  is  selected. 
The  node  is  expanded  for  all  the 
possible  outcomes  (windows)  for  this 
new  sensor.  The  probability  of 
correct  classification  at  each  new 
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nod*  i*  than  coaputad  and  tarainaX 
indicators  ar*  addad  to  aach 
finiahad  branch. 

As  part  of  th*  initialisation,  th* 
algorithm  computaa  th*  a  priori 
probability  that  a  sanaor  j  will 
raport  a  valu*  in  window  k> 

P(Oi)  *  P(Wj)ilOi)  (1) 

This  rasult  is  usad  to  comput*  th* 
probability  that  th*  objact  baing 
obsaarvad  is  of  typo  i,  given  that 
sansor  j  has  raported  a  raading  in 
window  k: 

P(Oi|Wjk)  -  (P<Oi)  *  P<WjklOi))/ 
P(Wjk)  <2) 

Tha  next  atap  is  to  compute  the 
probability  that  the  object  is  of 
type  i  given  a  sequence  of  windows 
for  the  sensors  which  have  already 
ean  used.  If  is  a  list  of 

windows  (k)  for  sensors  (j),  then: 

P(Oi|{Wjk})  >  (P(On  *  Hjk 

P(Wjk|Oi))/P<Wjk>  <3) 

This  equation  is  true  because  the 
sensors  are  conditionally 
independent.  If  pairwise  (or  n- 
wisa)  relationships  exist  between 
the  sensors  for  a  given  object- 
class,  these  clusters  are  identified 
as  distinct  objects  or  variants  of 
objects  in  the  environment. 

If  the  conditional  probability  in 
Equation  3  exceeds  the  required 
confidence  level  for  some  i,  this 
branch  stops  and  a  terminal 
indicator  consisting  of  a 
classification  is  added.  If  not, 
all  the  unused  sensors  are  evaluated 
to  determine  which  will  provide  the 
greatest  payoff  in  new  information 
per  unit  cost.  To  do  this,  we  use 
the  formula  for  the  remaining 
uncertainty  about  the  environment 
given  the  windows  {Wj|^}  which  have 
been  reported  to  date: 

H(ol{Wa^})  -  P(Oil{W.^})  * 

P<OiUWjk>) 


and  th*  formula  for  tha  uncertainty 
which  will  remain  aftar  using  a  new 
sansor  (j')  with  windows 

H(Ol{Mjij>A(Hj.k-))  -  -  Si  Sj.. 

P(OiA(j‘,k*y|{Wj,j})  *  Logj 

P(Oi|(Wj,j>A(Wj..k*)>  <5) 

whara  P(Wj.^. )  is  the  a  priori 
probability  of  occur ranc*  of  window  k*' 
for  sanaor  j*: 

P(W^.^..)  -  P(Oi)  •  P{Wj.,j.|Oi)  (6) 

Th*  naw  sansor  (j‘)  which  swximixas 
th*  diffaranc*  between  formula  4  and 
formula  5,  divided  by  th*  response 
time,  is  tha  one  which  contributes  th* 
most  new  information  per  unit  coat,  so 
this  sensor  is  used  to  expand  tha  nod* 
being  worked.  The  evaluation  of  th* 
new  nodes  proceeds  depth  first,  from 
front  to  back  until  there  is  a 
solution  at  the  end  of  every  branch, 
or  the  process  runs  out  of  sensors  and 
fails. 

For  a  more  detailed  discussion  of  the 
information  theoretic  equations  used 
in  this  program,  see  Refaranc*  S. 

6.  PROGRAKHIMG  mFORMATIOM  AMD 
COMPLEXITY  ANALYSIS 
This  algorithm  was  coded  in  PC  Scheme, 
a  version  of  LISP  produced  by  the 
Texas  Instruments  Company.  Th* 

elements  of  Scheme  syntax  used  for 
this  program  are  reasonably  standard 
for  LISP. 

The  complexity  (C)  of  the  algorithm 
described  in  this  paper  is  on  the 
order  of: 

C  *  N(i)  *  N(j)  *  Ilj  N(k(j))  (7) 

where: 

o  N(i)  is  the  number  of  object 
classes  in  the  environment 

o  N(j)  is  the  number  of  sensors 

o  N(k(j))  is  the  number  of  windows 
(k)  for  sensor  j. 


Logj 

(4) 


Sine*  «ll  sub««t«  of  th«  posaibla 
■•naors  to  ba  uaad  on  aach  branch 
auat  ba  conaidarad  in  tha  globally 
optinal  algorithm,  tha  complaxity 
(O'*)  ia  on  tha  ordar  of: 

C-  -  H(i)  *  2**N(j)  *  Ilj  N(lc(j))  (8) 

whara  tha  middle  part  of  the 
expreaaion  ia  the  number  of  aubaeta 
of  a  aet  of  N(j)  elementa. 

For  example,  if  there  are  five 
object  claaaea  in  the  environment, 
five  aenaora  and  five  windowa  for 
each  aensor,  the  complexity  of  the 
algorithm  in  thia  paper  ia  on  the 
order  of  78,125  whereaa  the  optimal 
algorithm  ia  484,375. 

If,  aa  ia  probable,  we  are  able  to 
apecify  the  firat  aenaor  to  be  uaed, 
the  complexity  ia  reduced  to  12,500 
and  48,875  reapectively .  If  we 
apecify  branchea  of  the  deciaion 
tree  which  are  already  aatiafactory, 
the  deaign  taak  can  be  further 
aimplif led. 

7.  PLANNED  ENHANCEMENTS  AND 
APPLICATIONS 

The  LISP  veraion  of  the  algorithm  ia 
regarded  aa  an  exploratory 
prototype.  Thia  language  ia  a 
convenient  prototyping  tool  for  an 
algorithm  of  thia  type  because  LISP 
programs  are  inherently  modular  and 
recursion  is  very  easy  to  implement. 
The  program  is  currently  being  re¬ 
hosted  in  C++. 

The  next  module  being  developed  will 
provide  a  front  end  for  the  existing 
algorithm  so  that  the  design  of 
decision  logic  will  be  a  turnkey 
operation.  The  input  will  be  a  data 
base  containing  the  distributions  of 
the  values  of  attributes  of  the 
objects  in  the  environment.  The 
NATO  Emitter  Data  Base  is  an 
example.  The  new  module  will  find 
overlaps  in  attribute  values,  create 
windows  and  compute  all  the 
conditional  probabilities  needed  to 
complete  the  knowledge  base. 


Aa  one  of  several  exercises  done  with 
the  algorithm,  the  author  has  used  it 
to  design  Radar  Warning  Receiver  (RWR) 
logic  for  an  environment  consisting  of 
four  radar  threats.  Parameters  from 
the  NATO  Emitter  Data  Base  were  used. 
Simulated  intercepts  of  a  fifth  threat 
were  then  introduced  to  exercise  the 
learning  module.  The  resulting 
decision  logic  was  further  tested  in 
an  RWR  simulation  driven  by  the  STC 
Radar  Environment  Simulator  (RES). 

8.  CONCLDSION 

If  sensors  provide  different  amounts 
of  information  and  have  different 
costs  associated  with  their  use,  the 
design  of  an  optimal  strategy  for 
sequential  constraint  satisfaction 
using  these  sensors  is  an  NP-Complete 
problem.  Thia  paper  contains  a 
description  of  a  sub-optimal  design 
algorithm  which  reduces  the  complexity 
of  the  problem.  The  algorithm  also 
allows  the  user  to  specify  part  of  the 
solution  to  reduce  the  complexity  even 
further.  This  algorithm  applies  when 
the  probability  distributions  of 
sensor  readings  are  known  for  all  the 
object  classes  in  the  environment,  but 
when  there  is  inherent  ambiguity 
(overlap)  between  the  distributions. 
It  is  useful  whenever  efficiency  at 
run-time  is  important.  The  algorithm 
has  been  implemented  in  LISP.  A 
comprehensive  set  of  diagnostics  and  a 
learning  module  are  provided. 
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Discussion 


Question  L.  HOEBEL 

Do  you  have  any  conjecture  abou  the  effect  of  users  on  complexity  for  large  scale  problems,  that  is.  with  more 
rad^parameters,  do  users  have  more  or  less  effect  on  softwtse  (operatioa)  complexity? 

Reply 

The  relatkMiships  between  the  "complexity"  in  the  environment  and  the  complexity  of  the  algorithm  is  given  in  the  paper. 
As  the  environment  grows,  the  increase  in  computational  complexity  will  outpace  improvements  in  processing 
power/speed.  The  domain  expert  will  have  to  do  more. 
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SUMMARY  INTPQPgCIlgN 


This  paper  is  presenting  a  methodotogy  for  the 
integ^tion  ot  an  expert  system  in  an  embedded  real 
time  software  rimningthe  VRTX  operating  system. 
We  define  the  ‘Expert  Unit*  concept  and  its  life 
cyde  referring  to  a  real  experimentation  The 
production  of  operational  embedded  expert  system 
becomes  a  reality  because  of  the  use  of  efficient 
tools  and  an  original  methodology  for  its  integation. 

This  paper  is  showing  how  software  engineering 
techniques  and  methods  (Life-Cycle  definition, 
identification  of  generic  configuration  items)  can 
help  an  embedd^  expert  system  development  to 
be  more  efficient  and  conYoUaUe  than  by  using  the 
Boehm's  spiral  model.  This  Life-Cyde  is  compatible 
with  military  quality  standards  (GAM  T17  and  DOO 
2167a). 

An  expert  unit  is  a  software  component  which  may 
be  integrated  as  other  (conventional)  components 
of  the  application  but.  as  including  knowledge,  it 
should  be  developed  with  spedfic  methods  and 
tods.  Its  stucture  is  also  apecKk  and  indudes  3 
parts:  Knowledge  base.  Data  interfaces. 
Programming  inteHace.  This  structure  is  using  the 
‘ab^act  obj^s*  XIA/XRete  tod's  facility. 

These  development  life-cycle  and  Expert  Unit 
concept  imply  a  new  design  approach  of 
Knowledge-^sed  Systems.  Oiring  the  definition 
phase,  the  compwents  of  the  application  and  their 
functions  are  defined.  Some  of  ^em  are  identified 
as  heuristic  or  decisional  (knowledge  based) 
functions  in  the  application.  Specific  kfe-cycle  is 
then  applied  to  these  functions.  A  KBS  becomes  a 
software  where  expert  units  which  encapsulate 
knowledge,  and  classical  components  are 
integrated. 

The  work  desaibed  next  is  a  complement  of  the 
work  done  by  Thomson-CSF/RCM  to  apply  expert 
system  techniques  to  the  problem  of  radar 
identification.  This  work  has  been  carried  out  within 
the  Thomson-CSF  XIA/XRete  project. 


We  use  to  assume  that  an  expert  sydem  is  basically 
different  from  a  classical  software.  A  conventional 
software  is  made  up  variables,  functions  and 
procedu’es.  But  an  expert  system  is  made  up  an 
inference  en^e  vi4uch  is  a  classical  software  and  a 
kno^dge  base  that  contains  inference  rules  gven 
by  the  human  expert,  elicited  and  formalised  by 
knowledge  engineer  and  exploited  by  the  inference 
engine. 

It  implies  that  a  set  of  specific  methods  and  tools 
have  to  be  used  in  the  development  of  a  software 
which  includes  a  knowledge-based  function 
Furtftermore,  this  set  is  used  on  the  whole  software 
development  An  application  is  a  dasakal  software 
or  an  expert  system. 

In  real  world,  most  of  applications  vdiich  we  need  to 
develop ,  contains  functions  which  are  typically 
algorithmic  and  others  which  are  typically  heuristic  or 
decisional.  Both  ot  it  have  to  work,  communicate  and 
interface  each  other  First  technical  solution  consist 
in  design  of  complex  systems  which  inter  couple 
dassicaJ  software  and  expert  systems. 

Such  a  solution  cannot  be  chosen  for  embedded 
military  application  development.  Coupling  is  not 
enough  efficient  to  respect  operational 
requirements  (execution  time,  memory  space).  To 
respect  such  requirements  the  expert  symem  have 
to  be  deeply  (completely)  inte^ated.  An  expensive 
solution  is  to  develop  anymore  the  expert  S)^em  in 
procedural  language. 

In  1984,  new  techniques  of  rule  base  total 
compilation  happend.  With  these  techniques,  the 
integration  of  an  expert  system  in  software  becomes 
possible  [Fagesee]  [Fages  86].  The  result  of  this 
work  is  the  XIA/XRete  tool,  a  real-time  expert  system 
workbench.  XIA/XRete  is  composed  of  a  rule  base 
compiler  which  generates  target  procedural 
language  (C,  C++.  LTR3  or  LISP)  from  rule  base 
written  in  rule  language  and  of  an  inference  engine. 

This  paper  is  introducing  the  methodological  and 
desi$p  approach  associated  to  this  kind  of  tools.  It 
preserves  creativity  during  Mock-up  phase,  all  the 
development  products  are  re-used  over  the  life- 
cycle  and  no  constraint  is  imposed  by  the  expert 
system  on  the  application  architecture. 
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H«r«  is  dsfinsd  fhs  “Expert  Unit*  concept  and  its 
Lifs-Cyds.  It  has  to  be  compatible  with  classical 
software  life-cycle  [BoehmSI]  (GAMT17| 
(0002167).  It  is  also  d^ved  from  the  ESA's  expert 
system  life-cycle  [ESA85].  And  the  productivity  is 
increased  by  comparison  with  the  spiral  model 
(BoehmSfi). 

Usually,  an  expert  system  is  a  complete  software 
where  all  parts  of  it  (algorithmic  or  heuristic)  are 
designed  as  an  expert  system  In  a  software 
development  process  an  expert  system  component 
impose  an  “hegemony*  i.e.  the  other  components 
have  to  adapt  their  external  interfaces  to  be  able  to 
work  with  it.  In  this  way.  development  process 
becomes  more  difficult  and  expensive 

The  Expert  Unit  concept  has  been  defined  to 
control  more  efficiently  embedded  knowledge- 
based  systems  development.  This  objective  has 
been  reached  by  looking  upon  expert  system  just  as 
another  software  component.  So  that  software 
engineering  techniques  and  methods  may  be 
ap^ed  on  it.  This  is  possible  by  designing  the 
expert  unit  as  made  up  three  parts  which  are  the 
three  configuration  items  defining  completely  an 
expert  unit: 


Figure  1  :  Expert  Unit  Structure 


The  three  configuration  items  are: 

-  knowledge  base 

The  knowled^  base  is  the  item  where  expert's 
knowledge  is  elicited  in  rule  language.  The 
knowledge  base  is  the  mae  specific  item  of  the 
configuration  because  it  contains  no  classical 
programming  code.  It  gives  the  expert  nature  of 
the  expert  unit  configuration. 


The  applKabie  tools  are  the  rule  compiler  then  if 
need^  the  target  language  comprier  This  is 
developed  in  the  mock-up  environment  by  a 
knowledge  engmeer 

This  is  an  element  (referring  to  [0002167]) 
because  considered  as  a  compilation  unit.  The 
element  concept  needs  to  be  adapted  because 
this  item  may  be  compiled  two  bmes  (orKe  by  rule 
base  compiler  and  once  by  target  language 
compiler) 

In  the  nght  way.  the  knowledge  base  must  be 
compleMy  developed  at  the  end  of  the  mock-up 
phase 

It  is  pMstble.  in  a  pragmatic  way.  to  develop,  in  a 
first  time,  an  incomplete  knowledge  base  to 
integ'ate  it  in  the  application  and  to  teat  it  sooner 
with  real  data.  In  this  case,  the  final  and  complete 
knowledge  base  could  be  obtained  incrementally 
by  successive  changes.  This  way  is  not 
particularly  useful  because  controlling  the 
convergence  of  this  succession  of  changes  is 
very  diifrcult. 

-  data  interlaces 

Data  interfaces  are  made  up  implementation 
directives  of  absfract  objects  (objects  handed  by 
knowledge  base  and  physically  located  in  the 
application's  data)  and  interfacing  primitives 
Imptementation  directives  use  interfacing 
primitives  to  access  to  objects  vtrfues. 

All  data  transfers  between  the  knowledge  base 
and  the  application  must  be  done  through  data 
interfaces. 

In  our  experimentation,  data  interfaces  use  the 
abstract  object  facility  of  the  XIA/XRete  tool 
|XIA91].  This  facility  lets  handle  (abstract)  objects 
in  the  krtowledge  b<»e  as  the  expert  want  to  see 
them  independently  of  their  real  implementation 
or  location.  So  it  lets  specify  formally  for  each 
object  and  its  attnbutes  how  to  calculate  their 
value 

The  applicable  tools  are  the  rule  base  compiler 
(for  implementation  directives)  and  the  target 
langua^  compiler  (for  primitives).  Data  interfaces 
are  produced,  integrated  and  tested  in  the  Mock- 
up  environment  by  knowledge  engineer  for 
implementation  directives  and  ^tware  engineer 
(from  the  application's  team)  for  interfacing 
primitives. 

Data  interfaces  are  a  component  (referring  to 
(DOD2167I)  because  they  are  not  a  compilation 
unit.  They  are  composed  by  two  parts  which  are 
compiled  by  two  different  compilers. 


Data  intarfacas  ara  davalopad  during  tha 
prototypa  phaaa  Changaa  of  knowladga  baaa 
bring  to  data  intarfacas  changaa. 

-  prog'amming  interfaca 

Tha  programming  intarfaca  contains  all  tha 
function  and  procadura  ratarancas  batwaan  tha 
axpart  unit  and  tha  application  and  tha  antry 
point  of  tha  axpart  unit  (infaranca  loop).  It 
contains  all  tha  links  (in  or  out)  with  tha 
application  in  tha  can  graph. 

Applicabla  tools  ara  rula  basa  compilar  (to 
compila  rula  languaga  primitivas)  and  targat 
languaga  compilar.  Tha  prog'amming  intarfaca  is 
first  davalopad  by  a  knowladga  anginaar  in  tha 
Mock-up  anvironmant  to  simulata  tfM  application 
working  and  rawrittan  in  tha  application 
anvironmant  during  tha  axpart  unit  pfMsa  by  a 
software  anginaar. 

Progamming  interface  is  an  elamant  (referring  to 
(DOD2167])  as  tha  knowladga  basa. 

Below  is  desaibad  tha  Expert  Unit  Life-Cycle 
integated  into  tha  application  V  Life-Cyda. 

Tha  Expert  Unit  Lifa-Cycia  is  made  up  three  main 
phases,  an  optional  phase  (Knowledge  Basa 
porting)  and  two  common  phases  with  tha 
application  life  cyde  (Definition  and  Intagation 
phases). 

Tha  three  phases  are: 

-  Mock-up  phase 

During  the  Mock-up  phase  the  expert  knowledge 
is  elicited  and  formalised  by  a  knowladga 
engineer  from  human  expert  than  the 
kn^edge  basa  is  developed.  Interfaces  with 
the  application  are  simulated. 

At  the  end  of  this  phases  the  knowladga  basa 
must  be  validated.  This  is  recommended  but  not 
{^sokitaly  necessary  as  we  have  seen  it  above 
(see  knoiMedge  base  description  section). 

All  tha  developments  ara  made  in  tha  mock-up 
environment  (LISP).  Application  constraints  are 
not  considared  in  the  mock-up  development. 

Stong  interactions  exist  between  Definition  and 
Mock-up  phases  because  of  the  faaa^ity  mock- 
up  which  is  necessary  in  most  of  cases. 

-  FYototypa  phase 


During  tha  prototypa  phase,  the  data  intarfacas 
ara  produced  by  considering  tha  application 
interfaces.  Data  interfaces  (implementation 
diractivas)  ara  developed  in  ^e  mock-up 
language  These  are  used  as  specifications  to 
develop  interfacing  primitivas  in  application 
development  languaga  Than  they  ara 
incremantafly  integated  to  tha  mock-up  which 
becomes  m  this  way  a  prototypa  After  each 
pnmitive  intagation.  no-ragassion  tests  ara 
appkad.  So  tha  prototypa  davalopmant  is  fully 
confollad  and  validated 

Tha  primitivas  are  developed  in  a  classical  way 
(with  software  engineering  techniquas,  tools  and 
methods).  Tha  prototype  is  produced  in  tha 
mock-up  environment  which  is  easier  to  use. 

-  Expert  Unit  phase 

During  Expert  Unit  phase,  tha  programming 
interface  is  rewritten  in  the  application  language. 

Tha  expert  unit  is  a  set  of  source  files  which  ara 
compiled  by  tha  rule  base  and  targat  languaga 
compilar  and  linked  with  tha  other  application 
units  in  the  embedded  application  environment 

Tha  KB  Porting  phase  may  be  necessary  if  another 
rula  baaa  compiler  (with  another  rule  language)  is 
used  in  the  application  environment.  But  it  is  not 
necessary  with  the  XIA/XRete  compiler  which 
generates  code  in  both  environments,  mock-up 
(LISP)  and  application  (C).  This  inaeases  the 
development  productivity  and  conkol 

The  intagation  of  the  axpart  unit  is  made  as  for 
other  units  of  the  embedded  application. 

Changes  are  made  from  tha  prototype.  Changes  of 
the  expert  unit  consist  essentially  of  changes  on 
knowledge  basa. 

Tha  complete  Expert  Unit  life-cyda  is  shown  in 
figure  2.  We  can  see  that  ‘prelimmr'y  design*, 
'bailed  design”  and  'coding  phases  are  raplacad 
by  ’Mock-up”.  'Prototype*,  (optional)  "KB  Porting 
and  'Expert  Unir  phases.  Tha  expert  unit  is  a 
software  component  which  is  pointed  out  as  an 
axpart  function  dirmg  the  'Definition'  phase. 

Productivity  is  gaatly  inaaased  because  all  tha 
developments  are  re-used  through  tha  whole  life- 
cyda  kom  tha  mock-up  (knowladga  basa)  to  tha 
axpart  unit  (data  intarfacas  and  progamming 
interface).  And  tha  davalopmant  process  becomes 
also  more  controllable. 

The  productivity  during  changes  is  also  increased 
because: 
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-  changes  are  made  from  the  prototype  in  the 
mock-up  environment  which  is  more  powerful 
and  user-friendly 

-  changes  are  made  essentially  upon  knowledge 
base  which  is  easier  lo  maintain  because  it  is 
more  modular  and  compact  than  its  equivalent  in 
procedural  language. 

I  estimate  that  changes  productivity  increased  about 
5  to  7  times  by  using  expert  system  techniques  in 
complex  functions  of  a  software. 

FBOM  A  MOCK-UP  TO  AN  EMBEDDED 
SOFTWARE 


Here  is  shown  how  the  methodology  described 
above  is  conaetely  applied  on  an  operational 
application. 

To  compare  the  performances  and  development 
efforts  we  develop  two  versions  of  the  same 
function: 

-  one  in  a  classical  way  in  procedural  language 

-  the  second  with  expert  system  techniques 


To  apply  the  expert  unit  Me-cycie.  is  to  integrate  the 
expein  system  mock-up  of  the  radar  identification 
function  in  a  real-time  embedded  software.  So  that 
the  mock-up  is  replacing  the  dasaical  equivalent 
component  of  the  embedded  software. 

The  embedded  software  running  the  VRTX 
operating  system  masters  a  radar  detector 
equipment.  Constraints  on  memory  space  and 
execution  time  are  very  strong.  Data  structures  are 
optimised  in  accordance  to  application's  information 
processing.  In  any  case,  they  are  not  adapted  to 
expert  ^tem  processing. 

The  mock-up  is  a  radar  identification  demonstrator 
developed  in  a  LISP  environment  on  VAX 
workstation  (for  more  details  see  (Galichet90|, 
|Schang66).  [SchangSSa)  and  [SchangSdb]).  So 
memory  and  time  constraints  are  very  weak. 

The  mock-up  knowledge  base  has  been  developed 
and  structured  as  shown  in  figure  3;  knowledge 
access  its  data  only  ihrou^  data  interface.  So  that 
physical  implementation  can  change  without 
bringing  to  changes  on  knowledge  base. 


4-5 


In  a  first  tim«.  C  primitives  are  developed  and  unit 
tested.  Then  LISP  primitives  are  replaced 
Incrementally  by  ther  equivalent  C  primitives.  At 
every  replacement,  non-regresaion  automatic  tests 
are  applied  to  detect  any  error.  This  vrorlc  permit  to 
obtain  the  prototype  which  can  access  from  LISP 
environment  to  application's  data  in  their  exact 
format  through  LISF^  interface.  It  ^arantees  also 
that  the  prototype  is  functionally  identical  to  the 
mock-up  (see  |Cagnache92]  for  more  details). 


Because  the  XIA-C  tool  became  available,  we 
translated  the  knowledge  into  XIA-C  syntax.  This 
translation  has  been  automatically  made  to  ensure 
consistency  between  prototype  and  expert  unit. 


Then  this  set  of  XIA-C  and  C  source  files  are 
compiled  to  obtain  object  files  which  can  be  Imked 
with  other  obtect  files  of  the  appliciSion  as  anyone 
else  In  this  way.  we  otXain  an  executable  program 
file  that  we  can  experiment  and  compare  to  the 
“d*»mcat  one 


Figure  S :  Teady-to-mte^ate'  Expert  Unit 


The  performance  of  the  expert  unit  presents  the 
same  dfficulties  on  the  same  cases  as  classical  unit 
But  the  performances  of  the  expert  unit  are  worse 
than  the  classical  one  by  a  significant  factor  which  is 
vanabie  (see  {Cagnache92)  for  more  details). 

This  variability  of  the  performance  factor  may  be  a 
mater  to  produce  really  operational  expert  units.  I 
suppose  that  we  wM  never  can  produce  expert  units 
which  have  same  performances  as  classical  one 
Because  the  code  of  classical  unit  is  opbnnised  for 
one  particvriar  application  but  the  expert  unit  code  is 
generated  by  the  rule  base  compilw  which  cannot 
be  so  efficient.  The  deference  dl  performance  is  the 
cost  of  generic  processing  of  knowledge 
management. 

Some  work  is  done  to  get  better  performance.  We 
obtain  some  significant  results 

-  worst  performance  cases  became  better  in  a 
significentway 

-  inference  engine  has  been  optimised  and  tNs 
work  gives  the  best  performances  improvement 

So  that  we  can  say  that  we  can  use  expert  system 
techniques  in  reasonably  time  conskained  soff^e 


m 


•  • 


•  • 
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COMCLUSIOM  AMD  PERSPECTIVES 


In  this  papsr  ws  havs  dshnsd  a  KBS  Lifa-Cyda  to 
maka  its  davelopmant  and  intagration  more 
controllabla.  This  approach  is  based  on  the  expert 
unit  concept. 

An  expert  unit  is  a  software  component  which  may 
be  mte^ated  as  other  (classical)  components  of  the 
application  but,  as  containing  (encapsulating) 
kn^edge,  it  should  be  developed  with  specific 
methods  and  tools. 

Its  skucture  is  also  specific  and  is  made  of  3  parts: 
Knowledge  base.  Data  interfaces  through  which  the 
knowled^  base  access  to  application's  data, 
Programming  interlace  through  which  the  expert 
unit  IS  called  by  the  application  and  the  expert  unit 
calls  other  units  of  the  application. 

In  the  expert  unit  life-cyde.  activities  are  clearly 
behaved.  Mock-up  phase  adckesses  the  knowledge 
base  development,  prototype  phase  the  data 
interfaces  development,  expert  unit  phase  the 
pro^amming  interface  development  The  KB 
porting  phase  is  optional  because  not  necessary  if  a 
tool  like  XIA/XRete  is  available  (XIA/XRete  works  on 
both  environments,  mock-up  and  application).  Then 
the  expert  unit  is  integrated  with  o^er  components 
of  the  application  in  a  dassical  way. 

Changes  are  made  from  the  prototype.  All  the 
devei^ments  are  re-used  over  the  whole  life-cyde. 
So  that  development  process  productivity  is 
increased 

This  life-cycle  is  compatible  with  military  quality 
standards  GAM  T17  and  DOD  2167a.  These 
development  Nfe-cyde  and  Expert  Unit  concept 
implies  a  new  design  approach.  Durmg  the  definition 
phase  the  components  of  the  application  and  their 
functionality  are  defined.  Some  of  them  are 
identified  as  heuristic  or  decisional  functionality 
(knowledge  based)  in  the  application.  Then  specific 
life-cyde  are  applied  to  them.  A  Knowledge  Base 
System  becomes  a  software  where  expert  unit 
which  encapsulate  knowledge,  and  classical 
components  are  integrated. 

Time  performances  of  exp^  unit  are  worse  but 
comparable  (in  a  significant  scale)  to  the 
performances  of  a  dassical  equivalent  unit.  They 
become  better  by  optimising  knowledge  base  ar)d 
inference  engine.  Some  work  is  actually  done  to  get 
them  better. 

This  life-cycle  needs  to  be  completed  by  a 
knowledge  base  development  method  (from 
knowledge  elidtation  to  Knowledge  Base  design 
and  codng). 


Quality  standards  need  to  be  adapted  to  alowed 
integration  ot  knowledge  bases  in  embedded 
softvwe 

Embedded  intelgerKe  becomes  a  reality. 
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At' 


RESUME 

Apr9s  une  presentation  du  systeme  de 
commandos  de  vol  (SCV)  du  RAFALE,  cet 
expose  decrit  les  travaux  mends  par  Dassault 
Aviation  dans  le  domaine  du  oenia  looiciel 
aPDliaue  aux  svstemas  critiauas  du  point 
de  vue  de  la  securite.  en  mettant  I'accent  sur 
les  points  suivants ; 

•  La  methodologie  de  developpement :  son 
originalite  reside  dans  I'ajout  d'une  dtape 
de  formalisation  des  specifications  de 
logiciel,  dont  I'objectif  est  de  renforcer  la 
qualite  du  dialogue  entre  deux  mondes 
distincts,  les  automaticiens  d'une  part,  les 
informaticiens  de  I'autre. 

•  Les  outils  cies  qui  supportent  cette 
methodologie ; 

•  GISELE  (Ref.1),  outil  de  specification, 
manipuiant  un  langage  formel,  dont  la 
puissance  de  test  et  la  possibilite  de 
prototypage  automatique  garantissent  la 
qualite  de  la  description, 

•  VALIRAF,  outil  de  validation,  qui  permet 
de  comparer  automatiquement  le 
systeme  realise  aux  modeies  eiabores 
en  phase  d'etude  et  de  specification,  et 
qui  assure  la  gestion  des  essais  dans  le 
but  (fen  evaluer  le  taux  de  couverture. 

Un  bilan  de  fexperience  acquise  et  une 
presentation  des  perspectives  de  travaux 
futurs  concluent  cet  expose 


INTRODUCTION 

L’accroissement  de  complexite  des  fonctions 


integrees  dans  les  systemes  de  commandes 
de  vol  a  nece^e  fintroduction  de 
calculateurs  numeriques  pour  les  mettre  en 
oeuvre.  Cet  organe  de  calcul  a  pose  un 
nouveau  probieme  de  securisation  des 
systemes.  En  effet,  alors  que  les  techniques 
de  securisation  des  elements  materiels  sont 
connues  et  eprouvees  (redondance,  vote  ...), 
la  securisation  des  logiciels  reste,  aujourd'hui 
emxire,  un  sujet  ouvert. 

A  I'instar  des  techniques  de  securisation  des 
materiels,  certains  recommandent  le  recours  e 
la  realisation  de  logiciels  N-Versions. 
fonctionnellement  equivalents,  instalies  dans 
les  N  calculateurs  du  systeme,  alors  que 
d'autres  preconisent  la  realisation  d'un  looiciel 
zero-faute.  replique  9  I'kJentique  dans  les 
calculateurs. 

Dassault  Aviation,  beneficiant  de  rexperience 
acquise  au  cours  du  developpement  de 
plusieurs  avions  dotes  de  calculateurs 
numeriques  assurant  des  fonctions  critiques,  a 
opte  pour  fapproche  logiciel  zero-faute.  Ce 
chobc,  conforte  lots  du  developpement  du 
demonstrateur  RAFALE  A,  suivi  de  ravion  de 
combat  operationnel  RAFALE  D,  a  mis  en 
evidence  la  necessite  d’integrer  dans  une 
meme  methodologie  les  travaux  de 
conce(Mion  fonctionnelle  (Ref.2)  et  de 
developpement  de  logiciel. 

Cette  methodologie,  dont  la  cie  reside  dans 
retape  de  formalisation  des  specifications  de 
logiciel,  renforce  Pintegration  des  differentes 
equipes  impliquees,  depute  la  conception 
jusqu'aux  essais  en  vol.  Elle  a  ete  eiaboree 
dans  un  contexte  particulier  (Dassault  Aviation 
developpe  entierement  les  SCV  de  ses 
avions),  mais  s'etend  aujourd'hui  e  des 
systemes  developpes  en  cooperation  ou  en 
sous-traitance. 


•  • 


Presented  at  an  AGARD  Meeting  on  ‘Aerospace  Software  Engineering  for  Advanced  Systems  Architectures’,  May  IdtrS. 
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LE  SYSTEME  DE  COMMANDES  DE 
VOL  DU  RAFALE 

Le  Systdme  de  Commandes  de  Vol  du 
RAFALE  assure  le  contrOle  de  I'avion  au 
moyen  d'un  ensemble  de  11  gouvemes  auquel 
il  faut  ajouter  les  2  moteurs  pour  certaines 
fonctions  particulidres.  Ces  gouvemes  sont 
utilis^es  conjointement  pour  r^aliser  un  certain 
nombre  de  fonctions,  pcrmi  lesquelles  on 
distingue: 

•  La  fonction  de  contrdle  du 

comportement  non  oilott.  qui  assure  les 
stabilisations  artificielles  statiques  et 

dynamiquesde  I’avion,  tant  en  longitudinal 
qu'en  transversal.  Cette  fonaion  realise 
^alement  le  contrOle  dynamique  des 
couplages  entre  le  SCV  et  les  modes 
avion  (modes  structuraux,  modes  de 
I'avion  sur  ses  atterrisseurs). 

•  La  fonction  de  contrOle  da 

comportement  pilotO.  qui  optimise  la 
rOponse  de  I'avion  aux  ordres  de  pilotage 
quelle  que  soil  la  phase  du  vol  (croisiOre, 
combat,  approche,  ravitaillement,  ...)  tout 
en  minimisant  la  charge  de  travail  du 
pilote  liOe  au  respect  des  limites 
aOrodynamiques  (incidence,  dOrapage)  et 
structurales  (facteur  de  charge,  ...)  de 
ravion,  la  protection  vis  0  vis  de  ces 
limites  Otant  rOalisOe  de  fafon 
automatique. 

•  La  fonction  de  contrOle  de 
configuration,  qui  optimise  I'utilisation  de 
I'ensemble  des  gouvemes  pour  adapter  au 
mieux  la  configuration  aOrodynamique  et 
structurale  de  I'avion  aux  conditions  de  vol 
et  aux  ordres  de  pilotage  de  fa9on  0 
exploiter  au  mieux  ses  capacitOs  de 
manoeuvrability  (marge  et  limite  de 
manoeuvre,  vitesses  de  roulis,  ...)  et  ses 
performances  (minimisation  de  la  traTnOe, 
vitesses  d'approche, ...). 

•  La  fonction  de  contrOle  de  ravion  marin  au 
catapultage. 

•  Le  couplage  du  contrOle  de  I'avion  0 
certaines  fonctions  opOrationnelles  (vol  0 
trOs  basse  altitude,  approche 
automatique). 

Line  part  importante  de  la  complexity  des 
traitements  fonctionnels  ryalisOs  par  le  SCV 
dycoule  de  la  nycessity  de  ryaliser  la  synthOse 


des  ordres  yiaborys  par  ces  diverses  fonctions 
tout  en  conservant,  en  cas  de  conflit  ou  en 
iimite  rfautority  du  systOme,  la  priority  aux 
fonctions  essentielles  (stabilisations, 
limitations  automatiques, ...). 

L'intygration  de  I'ensemble  de  ces  fonctions  au 
sein  d'un  systOme  de  Commandes  de  Vol 
Electriques  permet  done  d'optimiser  le 
comportement  gynOral  de  ravion,  avec  pour 
con^uence  I'homogynyisation  de  ce 
comportement  vu  du  pilote,  et  ce  pour 
I'ensemble  ytendu  des  configurations  utilisyes 
(masse,  centrage,  emports,  ...)  et  dans  tout  le 
domaine  de  vol. 

Cette  intygration  reprysente  un  volume  de 
traitements  que  seui  un  systyme  numyrique 
doty  de  calculateurs  de  forte  puissance  est  y 
myme  de  foumir.  Ces  calculateurs  exploitent 
les  informations  dyiivryes  par  un  ensemble  de 
capteurs,  mesurant  les  ordres  du  pilote  et  les 
mouvements  de  I'avion,  pour  yiaborer  les 
consignes  i  destination  des  actionneurs  qui 
pilotent  les  gouvemes. 

Se  basant  sur  I'expyrience  acquise  par 
Dassault  Aviation  dans  le  domaine  des 
Commandes  de  Vol  entidrement  yiectriques 
avec  les  programmes  M2000,  M4000  et  Mill 
NG,  expyrience  approfondie,  notamment  dans 
le  domaine  de  rutilisation  de  calculateurs 
numyriques,  par  I'expyrimentation  du 
dymonstrateur  RAFALE  A,  le  Systyme  de 
Commandes  de  Vol  du  RAFALE  est  doty 
d'une  architecture,  compatible  de  son  haut 
niveau  de  criticity,  basye  sur  une  redondance 
(fordre  4  de  ses  constituants  principaux.  Cette 
redondance  est  exploitye  de  maniyre  optimale 
par  le  biais  de  reconfigurations  automatiques 
en  fonction  de  I'ytat  d'intygrity  des  diffyrents 
constituants  du  Systyme. 

Dans  cette  architecture,  on  distingue 
(Planche  1) 

•  Les  capteurs,  de  redondance  4  pour  les 
plus  critiques  (capteurs  pilotes, 
gyromytres,  accyiyromytres,  ...),  de 
redondance  3  pour  les  autres  (capteurs 
anymo-baro-clinomytriques. ...). 

•  Les  traitements  fonctionnels,  de 
redondance  4,  constituys  de  3  chaTnes 
principales  numyriques,  d'architecture 
matyrielle  et  logicielle  identique,  associyes 
y  une  chalne  de  secours  analogique 
indypendante. 


yr 


•  • 


•  • 
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•  Les  actionneurs,  constitute  pour  les 
gouvemes  prindpales  (dievons  et 
drapeau)  de  servocommandes  6lectro- 
hydraullques  doubie  corps  A  4  entrtes. 

L'ensemble  de  ces  4l4ments  est  associ^  it  4 
alimentations  ^tectriques  et  2  circuits 
hydrauliques. 


LA  METHODOLOGIE 

La  realisation  de  nouvelles  fonctions  de 
contrdle  du  vol  a  ete  rendue  necessaire  pour 
repondre  i  revolution  des  besoins 
operationnels  des  avions  (farmes  modemes. 
La  possibilite  de  contrdler  des  avions 
instabies,  la  complexite  croissante  de  ces 
fonctions,  ont  renforce  leur  aspect  critioue  du 
point  de  vue  de  la  securite  et  impose  une 
mise  e  jour  progressive  de  leur  methodologie 
de  developpement. 

Les  puissances  de  calcul  mises  en  jeu,  non 
realisables  par  des  technologies  analogiques, 
ont  impose  I'introduction  de  calculateurs 
numeriques  et  le  recours  e  une  methodologie 
de  developpement  de  logiciels  qui  apporte  la 
conviction,  sinon  la  preuve,  d’obtenir  un 
logiciel  sans  defaut.  Cette  necessite  n'est  pas 
nee  au  logiciel  lui  meme  mais  e  la  fonction 
qu’il  met  en  oeuvre,  car  si  la  fonction  est 
critique  du  point  de  vue  de  la  securite  alors  le 
logiciel  I'est  aussi. 

Ces  methodologies,  chacune  dans  leur 
domaine,  apportent  la  garantie  d'un 
developpement  correctement  martrise  et 
minimisent  le  risque  d'introduction  d'erreurs. 
Force  est  de  constater,  et  ceci  bien  qu'evident 
est  souvent  neglige  tant  par  les  habitudes  de 
travail  que  par  les  normes  actuelles,  que  la 
source  la  plus  importante  d'introduction 
d'erreurs  se  situe  e  la  frontiere  de  deux 
metiers. 

En  effet,  alors  que  la  conception  fonctionnelle 
requiert  des  competences  en  dynamique  du 
vol  et  en  automatique,  le  developpement  de 
logiciel  necessite  des  competences  en 
informatique.  Nous  sommes  alors  face  d  un 
probieme  de  communication  entre  deux 
mondes,  qui  s'ils  ne  s'ignorent  pas,  bien 
souvent  ne  se  comprennent  pas. 


Partant  de  cette  analyse,  Dassault  Aviation  a 
congu  une  methodologie  qui  federe  Tensemble 
du  cycle  de  developpement,  depuis  fetape 
initiate  d'etude  fonctionnelle  Jusqu'e  la 
validation  finale  du  systdme  realise.  Tout  en 
apportant  une  solution  au  probieme  de 
communication,  le  caractere  de  continuite  du 
cycle  da  developpement  entraine  des 
possibilHes  de  verification  accrues  par  la 
reutilisation  dans  une  phase  quelconque  des 
jeux  de  tests  realises  dans  les  phases 
precedentes. 


La  methodologie  comporte  quatre  grandes 

etapes  (Planche  2) : 

«  CONCEPTION  la  Definition 

Fonctionnelle  (description  des  lois  de 
contrdle)  constitue  la  sortie  principaie  de 
cette  etape.  Les  etudes  de  definition 
s'appuient  sur  le  developpement  d'un 
Modete  Fonctionnel  (forme  executable  des 
algorithmes,  MF1).  L'activation  de  ce 
modeie,  dans  un  contexte  de  simulation 
aussi  rteliste  que  possible,  constitue  la 
verification  Fonctionnelle  (VF)  des 
algorithmes  au  regard  des  Specifications 
Globales,  et  clfit  retape  de  conception.  II 
est  important  de  noter  que,  des  cette 
etape,  I'utilisation  d'un  simulateur  temps 
reel  permet  de  fair®  participer  les  pilotes  e 
la  validation  des  choix  de  conception. 


«  FORMALISATION  :  c'est  l'6tape  de 
transition  entre  le  monde  des 
automaticiens  et  celui  des  informaticiens. 
C'est  pourquoi  le  langage  formel  utilise  a 
ete  congu  pour  etre  manipuie  et  compris 
par  ces  deux  mondes.  Cette  etape  est 
fondamentale  car  son  but  est  multiple  : 

•  c’est  une  revue  de  definition 
fonctionnelle  ;  pour  cette  raison  eile 
est  confiee  i  une  equipe  ayant  les 
memes  competences  que  requipe  de 
conception.  Ce  point  est  essentiel  car  il 
permet  d'assurer  une  relecture  active  de 
la  conception  dans  un  but  de 
reformulation. 

•  elle  produit  une  Definition  Technique 
Fonctionnelle  Formelle  (DTFF)  qui  est 
la  traduction  formelle  du  contenu  de  la 
Definition  Fonctionnelle,  dont  les 
qualites  (compietude,  coherence,  ...) 
peuvent  etre  verifiees  automatiquement 
pari'outil  GtSELE. 


S) 


•  • 
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•  un  motWto  •xicuttibte  (MF2)  de  la 
DTFF  est  obtenu  automatiquement  et 
utilisd  pour ; 

•  verifier  la  conformity  de  la  DTFF 
vis  y  vis  de  la  Oyfinition 
Fonctionnelle.  Cette  vyrification 
est  rdalisye  par  comparaison  du 
comportement  de  MF1  et  MF2 
(VL) 

•  dyfinir  les  tests  unitaires  et 
d'intygration  fonctionnellement 
reprysentatifs. 

La  conformity  de  la  DTFF  ytant  vyriTiye, 
rytape  de  ryalisation  est  engagye. 


•  REALISATION  :  le  dyveloppement  et 
rimplantation  du  logictel  dans 
ryquipement  sont  simplifiys.  On  tire  dans 
cette  ytape  un  grand  bynyfice  de  la 
formalisation  car : 

•  une  grande  partie  du  logiciel  est 
obtenue  par  codaoe  automatioue  de  la 
DTFF,  avec  pour  consyquence  un 
impact  favorable  sur  le  coOt  et  la  surety 
de  I'opyration, 

•  I'intygration  du  logiciel  dans 
I'yquipement  est  facilitye  par  le  jeu  de 
tests  yiabory  dans  rytape  de 
formalisation.  Cette  tdcbe  constitue  une 
oryvalidation  du  logiciel  (VI). 

La  pryvalidation  du  logiciel  effectuye,  on  quitte 
rytape  de  ryalisation  pour  entrer  dans  celle  de 
validation. 


•  VALIDATION  :  I'yquipement  ryel  est 
instaliy  dans  un  environnement  de 
simulation  fonctionnellement  reprysentatif 
qui  comprend  des  yquipements  ryels 
(capteurs,  servocommandes,  ...)  et  une 
modyiisation  temps  ryel  de 
I’environnement  (avion,  vent,  turbulence, 
autres  systymes,  ...).  Au  cours  de  cette 
ytape,  des  essais  sont  ryalisys  par  des 
pilotes  d'origines  diffyrentes  (ingynieurs, 
pilotes  (Tessais,  ...).  II  s'agit  done  d'une 
validation  globale  du  systdme  qui  prysente 
deux  aspects : 


•  yyrification  fonctionnelle  (VF)  vis  y 
vis  des  Spycifications  Globales,  gryce  y 
une  campagne  d'essais  dyfinie  lors  de 
rytape  de  conception.  Les  essais 
ryalisys  sont  suivis  en  temps  ryel  par 
les  ingynieurs  conce(4eurs. 
Simuttanyment,  les  signaux  nycessaires 
(entrys,  sorties,  ytats  internes  de 
ryquipement)  sont  systymatiquement 
enregistrys.  Ils  sont  ryutilisys  en  temps 
diffyry  pour  ytre  injectys  dans  un 
modyie  de  comportement  du  systyme 
comptet,  de  maniyre  y  s'assurer  que  les 
performances  obtenues  sont  conformes 
y  la  Spycification  Globale  (Planche  3) 

•  yyrification  du  comportement  du 
logiciel  (VL),  par  une  comparaison 
avec  les  modyies  MF1  et  MF2  soumis 
aux  mymes  sollicitations.  La  majeure 
partie  de  cette  activity  est  ryalisye 
automatiquement  par  I'outil  VALIRAF, 
que  nous  prysentons  en  dytail  dans  la 
suite  de  cet  exposy. 

C'est  y  la  vue  des  rysultats  de  validation  que 

I'on  autorisera  la  mise  en  vol  de  I'avion. 


L'OUTIL  GISELE 

L'outil  GISELE  (Gynyration  Interactive  de 
Spycifications  d'Ensemble  Logiciel  Embarquy) 
a  yty  dyveloppy  pour  assister  les  ingynieurs 
dans  la  rydaction  de  la  DTFF,  en  leur 
apportant  des  facilitys  de  manipulation  d'un 
langage  formel  que  nous  avons  congu  en 
tenant  compte  des  contraintes  suivantes  : 

•  le  langage  doit  permettre  de  dycrire  les 
traitements  y  implanter  en  restant 
indypendant  de  la  machine  cible  (matyriel 
et  langage  de  programmation), 

•  le  langage  doit  ytre  compryhensible  par 
des  personnes  qui  ne  sont  pas  des 
professionnels  de  I'informatique, 

•  le  langage  doit  permettre  de  ryaliser  des 
spycifications  dytailiyes  dypourvues 
d'ambiguny. 

•  les  spycifications  ainsi  ryaiisyes  doivent 
ytre  Tacilement*  validables. 


vD 


•  • 
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Pour  rApondre  A  ces  contraintes,  nous  avons 
MaborA  un«  moddlisation  de  robjet  A  spdcirier. 
Ce  module,  tout  A  fait  g^n4ral,  a  permis  de 
ddfinir  les  principaux  6l6ments  du  langage  qui, 
par  la  suite,  ont  affin^s  pour  aboutir  i  la 
creation  des  entit^s  suivantes : 

•  SYSTEME  (Planche  4)  :  son  architecture 
met  en  jeu  une  ou  plusieurs  ressources 
communiquant  entre  elles  par  un  r^seau. 
Le  *reste  du  monde*  est  consid^r^  comma 
une  ressource  qui  n'a  pas  d  6tre  sp^cifide, 

•  RESEAU  :  constitud  de  “boites  ii  lettres*. 
il  gdre  les  informations  6chang£es  par  les 
ressources  lors  d'actions  6l4mentaires 
d'4criture  ou  de  lecture  de  messages.  La 
chronologie  des  ^changes  peut  £tre 
contrainte  par  le  temps  (datation), 

•  RESSOURCE  :  elle  correspond  ii  un 
traitement  numdrique  individualist, 

’  indtpendant  des  traitements  des  autres 
ressources.  Une  ressource  est  une  entitt 
assurant  un  traitement  stquentiel  dont  la 
description  peut  ttre  hitrarchiste  en 
fonctions  (Planche  5), 

•  FONCTION  :  elle  est  dtcrite  selon  une 
approche  descendante  par  dtcomposition 
en  modules  organists  selon  une 
arborescence  slrictement  hitrarchique, 

•  la  function  de  plus  haut  niveau,  appelte 
fonction  principale,  constitue  le  point 
d'entrte  dans  la  description  des 
traitements  d'une  ressource.  C'est  la 
seule  autoriste  t  tchanger  des 
informations  via  le  rtseau, 

•  les  autres  fonctions,  appeltes  fonctions 
secondaires,  sont  monies  d'une 
interface  strictement  dtfinie  permettant 
d'assurer  que  leur  utilisation  est 
cohtrente  vis  i  vis  de  leur  dtfinition, 

•  MODULE  (Planche  6)  :  c'est  I'tltment  de 
base  de  la  description  des  traitements. 
Rtalist  sous  forme  d'un  organigramme. 
le  module  comporte  en  outre  des 
informations  gtntrales  (rtsumt 
fonctionnel  en  langage  courant,  date  de 
mise  t  jour  ...)  et  la  liste  des 
identificateurs  qu'il  manipule. 


•  ORGANIGRAMME  constitut  (fun 
ensemble  de  cadres  (qui  renferment  les 
expressions!  et  de  liaisons  (qui  figurent  la 
(ogique  de  stquencement),  il  est  soumis  t 
des  rtgles  de  syntaxe  adapttes  aux 
exigences  de  stcuritt  dont  les  principales 
sont ; 

•  entidrement  contenu  sur  une  page  A4, 

•  un  chemin  unique  d'entrte,  un  chemin 
unique  de  sortie, 

•  trois  structures  de  graphe  (Planche  7). 

•  EXPRESSION  ;  elle  d^crit  les  operations  i 
effectuer  sur  les  informations.  Les 
operateurs  autorises  sont  limites  e  : 

•  affectation  (:=), 

•  arithmetique  (+,  -,  *,  /), 

•  logique  (NON,  ET.  OU,  EQV). 

•  relationnel  (=.  /=.  >,  >=.  <,  <=), 

•  IDENTIFICATEUR  :  il  associe  un  nom  (8 
caracteres  maximum)  i  une  information. 
Chaque  nom  est  accompagne  de 
declarations  parmi  lesquelles  on  trouve  ; 

•  un  commentaire, 

•  un  type  (variable,  etat,  donnee  ...), 

•  un  format  (reel,  entier ...). 

•  une  unite  physique, 

•  les  valeurs  de  dimensions  (les  tables 
sont  limitees  i  quatre  dimensions), 

•  les  valeurs  (les  homes  de  variation  pour 
les  informations  dynamiques). 

La  structure  du  langage,  repond  aux  proprietes 

suivantes : 

•  GENERALITE  :  la  possibilite  de  decrire 
des  traitements  paralieies  ou  sequentiels 
avec  ou  sans  contraintes  temps  reel  est 
offerte, 

•  FORMALISME  ;  par  sa  rigueur,  il  permet 
de  rxintrdler  la  qualite  de  la  description,  et 
garantit  centre  la  possibilite  d'aboutir  i  un 
logiciel  dont  le  comportement  ne  serait 
pas  sur  (ecrasement,  blocage  ...).  De 
maniere  e  faciliter  retablissement  d'une 
DTFF,  des  conventions  du  langage 
permettent  fintroduction  de  description  en 
langage  usuel  (traitement  commente). 
Bien  entendu,  ces  traitements  ne  sont  pas 
testables,  mais  leur  integration  dans  une 
description  formelle  ne  supprime  en  aucun 
cas  les  possibilites  de  test  de  cette 
demiere. 


•  • 


•  LISIBILITE  :  baste  sur  une  description 
grapbique  (organigrammes),  la  partie 
textuelle  manipule  des  expressions 
matMmatiques  usuelies.  Les  details 
(dtelarteons,  vateurs  ...)  sont  d6portte 
dans  des  descriptions  en  annexe. 

•  TESTABILITE  :  il  ouvre  des  possibilitte  de 
test  impoftantes  parmi  lesquelles  on 
trouve ; 

•  test  structurel  (hi^rarchie,  graphe  des 
cbemins), 

•  test  syntaxique  (graphique,  textuel), 

•  test  de  coherence  (interface  de  fonction, 
unte  physique), 

•  test  de  flot  de  donates  (ant^cteence, 
d^bordement  de  table), 

•  test  de  compl^tude. 

•  CAPACITE  DE  PROTOTYPAGE 
I'obtention  automatique  d‘un  prototype 
executable  permet  d'assurer  que  la 
specification  du  logiciel  e  produire  est 
conforme  au  besoin. 


Realise  en  Fortran,  excepte  la  base  de 
donnees  qui  est  en  assembieur,  I'outil  GISELE 
est  implante  sur  les  ordinateurs  de  nos  centres 
de  calcul  (IBM  ES/9000). 

L'ergonomie  du  poste  de  travail  (ecran  IBM 
5080)  repose  sur  des  techniques 
conventionnelles  (multi-fenetrage,  menus 
contextuels  ...)  et  sur  un  editeur  syntaxique 
d'organigramme  (graphique  avec  placement 
automatique  des  cadres  et  des  liaisons) 
(Planche  8). 

La  production  automatique  de  document  est 
faite  surtraceurs  6lectrostatiques  (Planche  9). 

La  totality  des  regies  impos^es  par  le  langage 
est  v6rifi6e  par  des  fonctions  de  tests 
statiaues  dont  certaines  sont  peu  ou  pas 
implant^es  dans  les  outils  du  march^. 

On  cite  ici  pour  exemple  : 

•  le  test  d'ant6c6dence  ;  qui  consists  d 
v^rifler  que  tous  les  chemins  de  calcul 
aboutissant  k  I'utilisation  d'une  information 
ont  vu  cette  information  d^finie.  Le  dual 
consistant  i  verifier  que  toute  information 
d^finie  est  suivie  d'une  utilisation  sur  au 
moins  un  chemin, 

•  le  test  d'homoa6n6it6  :  qui  grdce  k  I'unitS 
physique  foumie  dans  les  declarations 
d'identificateur  assure  que  toutes  les 
expressions  sont  physiquement 
homogenes. 


Cependant,  le  respect  des  regies  du  langage 
n'est  pas  suffisant  pour  verifier  que  ce  que  Ton 
a  decrit  correspond  bien  k  ce  que  Ton  veut 
developper.  Grtlce  k  la  fonction  de 
generation  automatique  de  code 
executable,  cette  verification  est  possible. 

Le  code  genere  peut  etre  instrumente 
automatiouement  (insertion  de  tests, 
compteurs  d'activations  de  chemins). 
L'instrumentation  ainsi  realisee  est  utilisee 
pour  s'assurer  de  fexhaustivite  des  tests 
d'integration  et,  reprise  par  VALIRAF,  permet 
de  mesurer  le  taux  de  couverture  des  essais 
de  validation. 

Enfin,  la  production  d'un  code  intermediaiie 
Cpseudo-code'O  permet.  moyennant  le 
dteeloppement  du  traducteur  appropri^,  la 
realisation  automatique  du  logiciel  cible. 

Les  logiciels  de  commands  de  vol  des  avions 
de  type  RAFALE  D  ont  ete  ddveloppes  par 
cette  procedure. 


L'OUTIL  VALIRAF 

L'outil  VALIRAF  a  ete  developpe  afin  de 
realiser  d'une  fagon  quasi-automatique  la 
teche  de  validation  logicielle  du  logiciel  du 
systems  de  commandes  de  vol. 

On  rappelle  que  cette  tdche  s'inscrit  dans 
retape  de  VALIDATION  oil  I'equipement  reel 
est  irrstatie  et  essaye  au  banc  global  de 
simulation.  A  titre  indicatif  le  volume  d'essais 
realises  et  exploites  represents  plusieurs 
centaines  d'heures. 

L'outil  VALIRAF  est  constitue  de  plusieurs 
fonctionnalites  dont  la  procedure  de  mise  en 
oeuvre  est  precises  planche  10. 

II  repond  k  deux  missions  essentielles  ; 

•  La  validation  logicielle  proprement  dite, 
fondee  sur  la  comparaison  du  logiciel 
embarque  avec  les  modeies  MF1  et  MF2  : 

Lors  des  essais  au  banc  global  de 
simulation.  I'ensemble  des  signaux 
necessaires  k  la  validation  logicielle,  tels 
que  toutes  les  entrees,  toutes  les  sorties, 
tous  les  etats  internes  plus  quelques 
variables  intermediaires  sont  enregistres 
sur  bande  magnetique.  Ces  signaux 
subissent  un  pre-traitement,  destine 
essentiellement  e  verifier  I'integrite  des 
mesures,  puis  sont  utilises  pour  solliciter 
les  modeies  MF1  et  MF2. 
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Les  differences  des  valeurs  eiabotees,  e 
chaque  cyde  de  calcul,  par  le  togidei  et 
les  deux  moddles  MF1  et  MF2  pour  un 
mdine  terme  fondionnel  sont  comparees 
e  des  seuils  preddfinis.  En  cas  de 
depassement,  les  dcarls  correspondants 
sont  signalds  et  memorises. 

Tout  ecart  signaie  au  cours  du  traitement 
global  fait  I'objet  d’une  analyse  detaitiee. 
Cette  analyse  est,  dans  certains  cas 
simples  et  bien  identifies,  realises 
automatiquement  par  foutil  VALIRAF. 
Dans  te  cas  contraire,  elle  est  realisee  par 
I'ingenieur  au  cours  d'un  traitement  partiel 
des  essais  au  voisinage  des  instants 
signalant  les  ecaits.  Le  traitement  consiste 
alors  e  decomposer  le  terme  signaie  en 
ses  differents  constituants  pour  chacun 
des  modeies  MF1  et  MF2,  A  reperer  sans 
ambiguite  le  terme  amont  composant 
forigine  de  I'ecart,  puis  finalement  A 
eiaborer  un  diagnostic.  Durant  une 
campagne  de  validation  logidelle,  tous  les 
ecarts  doivent  etre  analyses  et  expliques 
afin  d'assurer  une  verification  compete  et 
totals  de  la  Definition  Technique 
Fondionnelle  Formelle  ainsi  que  de  sa 
realisation. 

•  La  aestion  dvnamiaue  des  essais  de 
validation  destines  e  assurer  et  mesurer 
la  compietude  des  essais  realises ; 

Au  cours  du  traitement  global  defini  ci- 
dessus,  sont  archives  en  Bases  de 
Donnees  (BDD)  certains  parametres 
representatifs  du  voi  d’une  part  (point  de 
vol,  mode  de  fonctionnement  du  SCV...)  et 
de  ractivite  ou  la  non-activite  des 
branches  fonctionnelles  d'autre  part. 

Cette  demiere  information  est  obtenue  par 
exploitation  des  compteurs  d'activation  de 
chemins  du  module  MF2  dont  foutil 
GISELE  a  assure  I'instrumentation 
automatique. 

L'expioitation  systematique  de  la  BDD 
permet  ,en  cours  de  validation  globale,  de 
completer  et  d'orienter  les  essais  vers  des 
programmes  susceptibles  de  parcourir  les 
branches  fonctionnelles  non-activees 
precedemment  et/ou  d’observer  le 
fonctionnement  du  systeme  avion  +  SCV 
dans  un  ensemble  de  conditions  de  vol 
representatives  de  son  utilisation  reelle. 


En  fin  de  campagne  de  validation, 
l'expioitation  de  la  BDD  foumit  une 
mesure  du  taux  de  couverture  des  essais 
realises. 


Realise  exciusivement  en  Fortran,  Toutil 
VALIRAF  est  aussi  implante  sur  les 
ordinateurs  de  nos  centres  de  calcul  (IBM 
ES/9000).  La  BDD  est  geree  par  le  Systeme 
de  Gestion  de  Base  de  Donnees  Relationnel 
ORACLE. 

VALIRAF  est  constitue  d'un  noyau  qui 
regroupe  tout  un  ensemble  de  sous- 
programmes  Fortran  permettant  de  realiser 
d'une  fagon  automatique  les  actions  de  lecture 
et  de  verification  de  validite  des  biocs  de 
donnees,  la  comparaison  des  parametres 
surveilies  avec  les  seuils  predefinis  ainsi  que 
reiaboration  des  diagnostics  automatiques, 
rinitiaiisation  des  modeies  MF1  et  MF2,  le 
trace  des  courbes,  I'eiaboration  de  statistiques 
associees  A  la  surveillance  des  ecarts,  e  quoi 
s'ajoutent  les  sous-programmes  propres  A  la 
BDD  tels  que  I'initialisation,  le  stocksge  des 
parametres  de  vol  et  le  stockage  des 
indicateurs  de  branches  de  MF2.  Ce  noyau  est 
invariant  vis  e  vis  de  toute  evolution  de 
logiciel  puisqu'il  realise  des  tdches  propres  A 
la  pror^ure  de  validation  logicielle  et 
independantes  de  la  nature  du  logiciel. 

Un  environnement  conversationnel  interactif 
invariant  vis  A  vis  du  logiciel  permet  d'activer 
le  traitement  global  systematique  des  vols  et 
les  stockages  en  BDD,  puis  de  mener  A  bien  le 
traKement  partiel  d'une  portion  de  voi  si  le 
traitement  gl;.ibal  a  mis  en  evidence  des 
ecarts,  ainsi  que  rintenogation  de  la  BDD. 

Un  certain  nombre  d'eiements  adaptes  au 
logiciel  i  valider,  comme  les  modeies  MF1  et 
MF2  ainsi  que  des  fichiers  (finterfaces 
enregistrements  /  modeies  MF1  et  MF2,  font 
partie  integrante  de  I'outil. 


L'EXP^RIENCE  ACQUISE 

Debut  1976,  le  developpement  du  'MYSTERE 
20  REGLEMENTATION”  (simulateur  volant 
d'avion  de  transport)  avait  donne  lieu  A 
rebauche  d'une  methode  de  developpement 
de  logiciels  embarques  critiques. 

Le  'MIRAGE  2000  NUM*  (developpement 
exploratoire)  a  ete  A  I'origine  de  la  version  1 
de  GISELE  dont  la  premiere  utilisation  a  eu 
lieu  en  Octobre  1983. 


4 


4 


4rj 


•  4 


•  4 


•  « 


•  i 


•  i 


5-8 


Riche  de  cette  experience,  la  version  2  de 
GiSELE  a  M  (Mveloppee  et  mise  en  service 
en  Janvier  1985  pour  le  RAFALE  A, 
accompagnee  en  Avril  1986  de  la  premidre 
version  de  VALIRAF. 

Les  retours  des  utilisateurs  ont  permis 
(fameiiorer  ces  outils  et  de  les  livrer  en 
Odcembre  1988  (GISELE  3)  et  en  Septembre 
1990  (VALIRAF  2)  dans  le  cadre  du 
progranune  RAFALE  0  dont  les  dvenements 
marquants  sont  les  suivants : 

•  premier  vol  du  C01  en  Mai  1991 

•  premier  vol  du  M01  en  D8cembre  1 991 , 

•  premier  vol  du  B01  fin  Avril  1 993, 

•  premidre  campagne  porte-avions  du  M01 
en  Avril-Mai  1993. 

Le  ddroulement  de  ce  programme  d8montre  la 
capacity  de  Dassault  Aviation  &  satisfaire  des 
objectifs  techniques  complexes  dans  le 
respect  des  d8lais  annonc8s  et  confirme  sa 
parfaite  mattrise  dans  le  domaine  du 
d8veloppement  des  logiciels  embarqu8s 
critiques. 


LES  PERSPECTIVES 

Les  m8thodes  et  les  outils  du  g8nie  logiciel, 
dar\s  toutes  les  8tapes  du  cycle  de  vie  des 
produits  d8velopp8s,  connaissent  actuellement 
un  ddveloppement  spectaculaire. 

En  ce  qui  conceme  l'8tape  de  spSciflcation  de 
logiciel,  la  disponibilit8  d'une  sp8cirication 
fonmelle,  telle  que  celle  qui  est  produHe  8 
I'aide  de  I’outil  GISELE,  constitue  la  base 
essentielle  des  travaux  de  g^nie  logiciel  8 
venir. 

Ces  travaux  seront  conduits  dans  les 
perspectives  suivantes : 

•  Accroissement  des  possibility  de  test  de 
la  specification  produite. 

•  Mise  en  oeuvre  (foutits  de  preuve.  Ces 
demiers,  aujourd'hui  de  possibilites 
restreintes  et  d'emploi  difficile,  pourront, 
dans  les  ann^es  8  venir  etre  ap^iques  8 
des  traitements  de  plus  en  plus  etendus. 

Par  ailleurs,  quel  que  soil  le  niveau  de  qualrte 
de  la  specification,  et  le  niveau  de  qualite  du 
logiciel  embarque  produit  (dont  la  realisation 
sera  de  plus  en  plus  automatisee),  le  besoin 
de  validation  du  systeme  realise  subsistera. 


Dans  ces  conditions,  revolution  de  routil 
VALIRAF  sera  conduite  selon  les  deux 
perspectives  principales  suivantes : 

•  Automatisation  de  la  preparation  et  de  la 
realisation  des  campagnes  de  validation. 

•  Automatisation  de  la  gestion  et  de  la 
synthese  des  informations  acquises  au 
cours  de  ces  campagnes. 

Enfm,  un  effort  constant  continuera  8  etre 
dedie  8  rintegration  des  methodes  et  moyens 
presentes  ici  (adaptes  particutierement  aux 
applications  critiques  du  point  de  vue  de  la 
sprite)  avec  les  environnements  de 
developpements  les  plus  repandus,  afin  que  : 

•  Par  remploi  d'Ateliers  de  Genie  Logiciel 
bien  adaptes  et  efficaces,  les  couts  de 
developpements  des  applications  soient 
aussi  rMuits  que  possible. 

•  Les  actions  de  cooperations  dans  le 
domaine  du  developpement  de  systemes 
embarques  puissent  etre  engagees  dans 
les  meilteures  conditions. 


CONCLUSION 

Dans  I'approcbe  Dassault  Aviation  du 
developpement  de  systemes  critiques  du  point 
de  vue  de  la  securite,  les  deux  points  deucats 
que  sont  le  transfer!  du  besoin  fonctionnet  aux 
realisateurs  et  la  mesure  de  la  compietude  des 
essais  de  validation  sont  couverts. 

Nous  ne  pretendrons  pas  que  la  methodologie 
de  developpement  et  les  outils  que  nous 
avons  presentes  constituent  I'unique  solution 
pour  obtenir  la  qualite  escomptee,  mais  le 
deroulement  du  programme  RAFALE  en 
demontre  refficacite. 
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1  ll^ODUCTlQN 

Since  the  eariy  Eighties  the  Object  Orioued  approach 
to  software  system  development  was  proposed  as  a 
possible  solution  of  the  so  called  ‘software  crisis’. 
The  claimed  benefits  were  that  Object  Oriented 
Design  (OOD)  had  the  potential  to  improve  software 
quality  by  making  possible  a  direct  and  natural 
correspondence  between  the  teal  world  and  its  model. 

Many  variants  of  the  original  approach  were  proposed 
and  the  new  traid  was  spread  across  the  Software 
Engineering  community. 

The  'traditional'  functional  oriented  methods  were 
suddenly  considered  out  of  date  and  not  appropriate 
to  support  development  of  large  teal  Ume  systems. 
There  were,  of  course,  some  drawbacks  but  they  were 
always  attributed  to  method  immaturity  and  poor  tool 
support,  two  self-solving  problems  as  time  passed. 
Ten  years  or  more  have  gone  since  then  and  OOD 
methods  have  been  widely  adopted  for  the 
development  of  large  distribute  real  time  systems. 

Are  the  lessons  learnt  from  such  projects  according  to 
the  expectations? 

Are  FiitKlional  Oriented  methods  still  able  to  support 
software  projects  of  the  size  required  by  the  Aerospace 
industry  in  the  years  leading  to  the  2000? 

This  paper  proposes  a  possible  answer  to  these 
questions  comparing  the  pro  and  cons  of  both 
methods. 

This  comparison  will  be  carried  out  on  issues  like 
transition  from  requirements  to  design  and  to  Ada 
code,  traceability  from  requirements  to  design, 
software  safety,  software  maintainability,  software 
testing  and  relationship  with  DOD-STD-2167. 

Let’s  start  with  some  general  principles  and  with  a 
brief  summary  of  the  salient  characteristics  of  both 
methods. 

2  THE  SOFTWARE  CRISIS 

The  increasing  complexity  of  onboard  navigation, 
guidance  and  control  systems,  together  with  the  trend 
to  implement  in  software  functions  traditionally 
accomplished  by  hardware  devices,  has  led  to  a 
situation  where  the  size  and  complexity  of  the 
embedded  software  has  become  utunanageable. 
Figure  I  shows  the  oustanding  growth  of  on-board 
software  for  modem  civil  and  military  programs. 


nOUDE  1:  OMOWTH  Of  OW  BOAWD  SOFTWAHC 


Indeed  in  the  last  years  virtually  all  software  projects 
nm  behind  schedule,  exceed  their  estimated  costs  and 
do  not  fully  meet  customer  requirements. 

This  situation,  known  by  the  software  community  as 
the  ’software  crisis’,  results  in  software  not  meeting 
its  requirements,  being  unreliable,  too  costly,  difficult 
to  change  and  maintaia 

Figure  2  displays  some  examples  of  Defence  projects 
that  overrun  dieir  planned  schedules. 
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As  each  author  tends  to  be  iimovative  and  doesn  ’t  want 
to  be  involved  in  copyright  quarrels,  the  literature  is 
full  of  different  dennitions  for  the  'software  crisis'. 
However,  the  common  factor  to  all  definitions  is  the 
difficulty  to  manage  the  extreme  complexity  of  the 
software  embedded  in  such  systems. 

The  design  and  implementation  of  systems  consisting 
of  millions  of  lines  of  code  require  an  effort  that  is 
cleariy  beyond  the  intellectual  and  physical  capacity 
of  a  single  person.  Of  course,  adding  more  people  to 
a  project  increases  the  overhead  due  to 
communication  and  coordination  problems. 
Furthermore,  the  fact  that  few  people  can  understand 
the  complete  structure  often  makes  the  process  to 
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modify  such  systems  a  lughtmare.  To  exacerbate  this 
obstacle  the  elusive  nature  of  the  software  itself 
typically  makes  challenging  even  to  focus  and  isolate 
the  sen^  problems. 

Besides  complexity,  other  acknowledged  causes  of 
the  software  crisis  are  the  shortage  of  trained 
persoimel  and  the  tending  of  people  to  resist  to  any 
new  trend  and  to  continue  using  archaic  metliods  and 
tools. 

Indeed  the  use  of  software  tools  and  techniques  to 
compensate  for  the  human  limitation  in  managing 
software  complexity  is  the  key  point  for  combating 
the  crisis. 

Proper  and  efficient  use  of  such  methods  and  tools  is 
the  discipline  commonly  known  as  Software 
Engineering. 

3  PRINCIPLES  OF  SOFTWARE  ENGINEERING 

The  first  goal  of  any  software/system,  development  is 
that  the  product  meet  the  specified  requirements. 
Unluckily  consistent  and  clear  requirements  are  rarely 
available.  Furthermore,  virtually  all  software  projects 
have  to  face  strong  constraints  related  to  timescale, 
hardware  development  obstacles  (e.g.  target  devices 
available  late  and  of  poor  quality)  and  integration 
problems. 

Among  the  outstanding  features  of  the  onboard  real 
time  software  systems  we  can  certainly  indicate 
modifiability,  efficiency  (in  term  of  time  and  space) 
reliability  (for  safety  critical  systems)  and 
understandability. 

To  achieve  these  goals  a  set  of  software  engineering 
principles  should  be  applied,  among  others; 

-  Abstraction  and  Information  Hiding 

-  Modularity  and  Localisation 

-  Completeness 

-  Testability 

The  complexity  of  a  typical  real  time  system  is  such 
that  a  leading  factor  for  a  successful  project  is  an 
appropriate  decomposition  of  the  system  into  simpler 
and  smaller  modules. 

To  define  consistent  criteria  for  the  representation  of 
a  real  system  and  to  support  its  decomposition 
countless  methodologies,  more  or  less  supported  by 
tools,  have  been  developed. 

Virtually  all  methods  can  be  divided  in  two  broad 
categories,  namely  the  more  traditional  Functional 
methods,  also  known  as  process-oriented  orstructured 
design  and  the  Object  Oriented  methods. 

The  latest  trend  of  some  segment  of  the  Software 
Engineering  community  is  to  consider  the  latter  the 
only  effective  answer  to  the  software  crisis.  Indeed 
OOD  supporters  tend  to  split  the  universe  in  OOD  and 
non-OOD  methods. 

To  represent  the  structure  of  the  system  under 
development  Functional  methods  adopt  a 


decomposition  resulting  in  design  elements  being 
compose  '  by  a  bunch  of  processes  while  in  an  OOD 
the  design  elements  directly  map  real  world  entities. 

In  order  to  better  understartd  the  scope  and  coment  of 
the  following  paragraphs  I  would  like  to  spetul  a  few 
words  on  one  of  the  most  important  features  of  a  real 
time  system. 

CorwurretKy  can  be  defined  as  the  capability  to  tun 
more  than  one  thread  of  execution  at  the  smne  time  on 
a  single  CPU,  thus  implementing  a  virtual  parallelism. 
Let’s  make  iui  example. 

An  aircraft  utility  system  may  be  tasked  to  coiurol  the 
speed,  the  oil  temperanire  and  oil  pressure  of  the 
engine,  the  turbine  and  the  related  gearbox.  Assuming 
the  system  encompasses  a  single  processor,  that 
results  in  a  total  of  six  different  activities  (functions) 
to  be  perfonned  continuously  on  the  same  CPU.  This 
means  that  the  functions  shall  tun  in  their  time  slices 
allocated  according  to  system  requirements  and 
scheduling  strategy.  In  our  example  the  six  fimctions 
could  be  grouped  in  three  processes,  controlling 
respectively  temperatures,  pressures  and  speeds.  The 
iteration  rale  of  each  process  will  depend  on  the 
features  of  its  implemented  functions,  e  g.  the 
temperature  control  will  have  less  stringent  timing 
requirements  than  the  turbine  speed  control,  where  a 
delay  of  few  milliseconds  can  result  in  over-speed  and 
consequent  hardware  damages.  Typically,  processes 
controlling  temperature  and  oil  pressure  run  at  S  to  iO 
Hz,  while  turbine  speed  control  may  require  up  to  2{X) 
Hz. 

To  design  and  implement  a  scheduling  mechanism  to 
manage  concurrent  issues,  possibly  with  the  use  of 
hardware  related  resource  (e.g.  interrupts)  and/or 
programming  language  features  (e.g.  Ada  tasking),  is 
one  of  the  most  critical  motif  in  the  development  and 
production  of  modem  real  time  system. 

H  living  givto  an  hint  on  concurrency  we  can  now  enter 
in  a  brief  de.sc''iption  of  the  two  methods  under 
examination. 

4  FUNCTIONAL  ORIENTED  METHODS 

As  said  above,  in  these  methods,  also  referred  as 
process  oriented,  the  system  reprc.sentation  is  based 
on  a  collection  of  processes,  each  performing  a 
function  (ora  SCI  of  functions)  that  is  pan  of  the  overall 
purpose  of  the  system  itself.  The  processes  operate  on 
data  rumiing  through  the  vanous  elements  of  the 
system. 

The  mapping  irum  the  real  world  entities  and  the 
.software  design  elements  is  not  straightforward  and 
such  mapping  is  even  less  evident  in  the  code 
structure.  This  can  make  difficult  to  understand, 
maintain  and  rcu.se  .such  code. 

On  the  other  hand  functional  decomposition  makes  it 
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easy  to  cope  with  seme  peculiar  aspects  of  real  time 
systenu  like,  for  examine,  concurrency  and  timing 
requirements. 

As  a  first  example  of  a  Functional  Method  we  will 
briefly  examine  MASCOT,  that  stands  for  Modular 
Approach  to  Software  Construction  Operation  and 
Test.  The  acronym  itself  identifies  the  salient  features 
of  the  method.  Modular:  the  key-point  of  the  method 
is  a  particular  fonnalism  by  means  of  which  a  complex 
software  module  may  be  broken  down  into  a  number 
of  interacting  smaller  components;  the  process  can.  of 
course,  be  iterated  until  required  to  pa^duce  a 
manageable  development  unit  Approach  is  a 
synonyms  of  Method.  Construction:  the  method 
incorporates  the  fimetions  to  build  the  software  and 
ensure  conformity  among  design,  source  code  and 
object  code  in  the  target  hardware. 

MASCOT  is  suitable  for  the  development  of  large 
distributed  embedded  systems.  The  emphasis  is  on  the 
large  in  all  its  significances:  large  number  of  involved 
people,  large  number  of  requirements  to  be  serviced 
simultaneously  (concurrency)  and  large  amount  and 
assortment  of  hardware  resources  to  be  handled. 

In  general  a  system  may  be  considered  as  consisting 
of  a  number  of  interconnected  internal  elements 
whose  combined  individual  operations  produce  the 
overall  effect  of  the  system  as  a  whole. 

The  MASCOT  representation  of  a  system  is 
characterised  by  two  basic  types  of  components,  the 
activities  and  the  data  areas  called  lOAs 
(Interconnected  Data  Areas).  In  a  system  the  elements 
of  the  two  types  are  interconnected  to  form  a  dataflow 
network,  consisting  of  active  elements  (activities)  that 
communicate  through  passive  elements  (IDAs). 
Appropriate  access  mechanism  are  implemented  to 
protect  the  integrity  of  the  data  and  to  ensure  the 
propagation  of  the  information. 

In  a  network  of  concurrent  processing  no  expli  ;it  time 
ordering  is  embedded,  although  a  priority  mechani.sm 
can  be  used  at  run  time  when  necessary. 

Another  category  of  non-object  oriented  methods  are 
the  ones  based  on  structured  analysis  and  structured 
design  techniques. 

The  first  step  on  a  typical  structured  system 
development  is  the  analysis  that  deals  with  "what"  a 
system  must  do.  The  result  of  this  phase  is  a 
specification  that  should  detail  thoroughly, 
accurately,  and  consistently  which  functions  the 
system  shall  implement. 

There  are  various  types  of  structured  graphical  forms 
to  prepare  a  specification  document,  but  they  are 
basically  similar.  Forexamplc  the  Yourdon/De  Marco 
variant  uses  three  basic  elements:  Data  Row  Diagram 
to  provide  a  graphical  representation  of  the  system, 
the  Data  Dictionary  to  add  written  description  of  the 
data  component  of  the  system,  and  Process 
Specification  which  describes  the  system  functions 
performed  on  these  data. 


Having  specified  "what"  a  system  is  supposed  to  do, 
our  development  should  move  into  "how"  it  shall  be 
implement,  that  is  the  Design  phase.  As  for  any 
other  (good)  methods,  structured  design  promotes 
foremost  software  design  practices  such  as 
modularity,  consistent  interface  definition  and  code 
reusability. 

Modularity  is  the  preminent  answerto  software  design 
problems,  specifically  to  complexity. 

A  graphical  representation  accomplished  applying 
modularity  rules  makes  the  system  easier  to 
understand.  Reducing  module  size  also  results  in 
software  units  that  are  easy  to  code  and  test.  Also 
changes  are  easier  to  control  and  implement  while 
theirconsequence  are  more  easily  uirderstood.  Having 
discussed  the  Yourdon/De  Marco  method  for  defining 
system  requirements,  similarly  we  can  consider  the 
Constantine/De  Marco  structured  design  approach  for 
software  design.  The  design  elements  are  simple,  few 
in  numberand  matching  the  Yourdon/De  Marco  ones: 
structure  chan,  data  dictionary,  and  module 
specification.  Their  description  is  much  the  same  of 
the  basic  elements  of  tiie  Yourdon/De  Marco. 

5  OBJECT  ORIENTED  METHODS 

Object  Oriented  Design  (OOD)  can  be  considered  a 
"new"  method  for  representing  the  real  world  in 
software. 

In  describing  a  system  two  main  entities  can  be 
identified:  the  objects  and  the  operations  applied  o 
those  object.  An  object  is  a  model  of  a  re^  world 
entity,  which  combines  data  and  operations  on  that 
data.  If  we  considered  our  utility  system  example  on 
Section  3.  the  engine,  the  turbine,  and  the  gearbox  are 
objects.  The  corresponding  operations  are  the  control 
of  the  oil  pressure,  temperature,  and  speed. 

Many  variant  of  the  original  OOD  approach  have  been 
developed.  One  of  the  most  popular  is  HOOD 
(Hierarchical  Object  Oriented  Design).  This  method 
combines  the  traditional  top-down  approach  with  the 
benefit  of  an  Object  Oriented  repre.senlalion.  allowing 
the  introduction  of  a  hierarchy  among  the  objects  in 
the  design. 

HOOD  has  been  developed  first  time  in  France  in 
1 987.  specifically  to  support  the  design  of  software  to 
be  written  in  Ada.  The  first  supporting  tool  has  become 
available  in  1988.  year  on  which  the  method  has  been 
adopted  by  ESA  for  the  Columbus  project.  In  1989 
the  new  Version  3  of  the  HOOD  Reference  Manual 
has  been  produced.  Other  tixilsets  have  been 
developed  and  HOOD  has  been  adopted  by  space  and 
industry  users  including,  in  19y().  the  European 
Fighter  Aircraft  (EFA). 

The  HOOD  design  strategy  is  globally  top-down  and 
consists  in  a  set  of  basic  design  steps,  in  w  hich  a  given 
object  (called  parent)  is  decomposed  in  smaller 
components  (child  objects)  which  together  provide 
the  entire  lunctionality  of  the  parent  object. 
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The  process  staits  at  top  level  with  the  root  object, 
which  represents  the  abstract  model  of  the  system,  and 
terminates  at  the  lower  level  where  only  terminal 
objects  are  present.  Terminal  objects  are  developed  in 
detail  and  directly  implemented  into  code. 

A  basic  design  step  is  in  itself  a  small  but  complete 
life  cycle.  During  the  various  phases  of  these  cycles 
the  software  requirements  are  understood  and 
restructured,  an  infomial  solution  is  outlirted  and 
described  in  terms  of  object  at  a  high  level  of 
abstraction.  Subsequently,  child  objects  and 
associated  operations  are  defined  and  a  graphical 
representation  of  the  solution  is  given  by  means  of  an 
HOOD  diagram.  Finally  the  solution  is  fomialised 
through  formal  description  of  object  and  operation 
control  structures.  At  the  end  of  this  phase  the  design 
structure  may  be  automatically  translated  into  Ada 
code. 

The  most  crucial  task  in  an  HOOD  design,  and  in 
general  in  any  OOD  variant,  is  the  identification  of 
the  objects.  In  fact,  while  it  can  be  intuitive  to  identify 
the  operations  it  can  be  tricky  to  distinguish  a 
consistent  and  appropriate  set  of  objects. 

The  theory  suggests  that  the  designer  firstly  express 
the  software  requirements  in  a  group  of  clear  and 
precise  definitions  (in  natural  language)  of  the 
requirements  themselves.  From  this  text,  nouns  are 
identified  as  candidate  objects,  and  verbs  are 
identified  as  corresponding  candidate  operations. 

To  represent  the  dynamic  behaviour  of  the  system, 
that  is  a  fundament^  aspect  of  real  time  systems.  Petri 
Nets  and  State  Transition  Diagrams  can  be  used. 
Among  the  main  principles  for  identifying  objects  we 
can  cite  hardware  devices  to  be  represented,  data  to 
be  stored  and  data  to  be  transformed. 

The  intent  of  an  object  is  to  represent  either  a  real 
world  entity  or  a  data  structure.  It  should  act  as  a  black 
box  hiding  the  data  and  allowing  access  only  by  means 
of  operations.  In  this  way  the  testing,  debugging,  and 
maintenance  are  eased. 

6  FUNCTIONAL  VFRSU.S  OBJECT  ORIENTED 

This  section  is  the  essence  of  the  paper  and  proposes 
the  comparison  between  the  two  methods  on  different 
aspects,  all  relevant  to  a  development  of  a  typical  large 
real  time  system  for  a  Defence  project. 

6.1  General 

When  assessing  the  suitability  of  a  method  to  support 
software  development  at  least  two  themes  must  be 
considered:  the  project  constraints  and  the  various 
aspects  on  which  the  compari.son  is  to  be  performed. 
Among  the  project  constraints  the  main  points  to  be 
considered  are  the  programming  language  and  the 
standards  and  procedure  to  be  applied. 

About  the  former  we  can  note  that  since  Mid  Eighties 
DoD  have  requested  Ada  as  programming  language 


for  their  applications.  As  a  consequence  Aca  has 
become  a  world-wide  standard  for  virtually  all 
defence  project. 

In  considering  standards  and  procedures  we  cannot 
forget  DOD-STD-2167.  This  widely  spread  standard 
states  the  requirements  for  the  implementation  of  a 
well  defined  and  consistent  software  development 
cycle,  the  related  monitor  and  control  activities,  and 
the  relevant  documentation.  Even  though  each  project 
has  its  own  standards,  they  arc  usually  derived  from 
2167  and  must  meet  its  requirements. 

In  our  comparison  we  will  consider  a  typical  project 
whose  standards  meet  the  requirements  of 
DOD-STD-2167  and  adopt  Ada  as  programming 
language.  This  situation  is  so  widespread  that  we 
consider  acceptable  to  limit  to  it  our  analysis. 

The  main  aspects  to  be  considered  in  comparing  the 
methods  are  identified  in  the  following  list: 

-  Support  to  Life  Cycle  Phases 

-  Software  Testing 

-  Software  Safety 

-  Software  Maintainability 

-  Relationship  with  DOD- STD-2 167 

6.2  Suppon  to  Life  Cycle  Phases 

DOD-STD-2 167(A)  defines  the  classic  "waterfall" 
cycle,  the  key  point  of  which  is  the  clear  distinction 
among  its  various  phases.  Prerequisite  for  passing  to 
a  new  phase  is  that  the  preceding  is  closed  and  its 
products  validated  at  a  Formal  Review. 

Main  phases  of  this  cycle  are  Software  Requirement 
Analysis,  Preliminary  and  Detailed  Design,  Coding 
and  Host  Testing,  and  Formal  Testing. 

Figure  3  shows  the  "waterfall"  life-cycle  as  defined 
by  DOD-STD-2 167(A). 

FIGURE  3:  DOO-STD-2167  SOFTWARE  UFE-CYCLE 
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Requirement  Analysis 

A  basic  principle  accepted  by  mo.st  parties  is  that 
whichever  method  is  chosen  it  should  be  applied  from 
the  beginning.  In  case  of  the  OOD  that  means  that  also 
the  requirements  should  be  expressed  in  an  object 
oriented  way 
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This  is  because,  as  we  have  seen,  functional 
decomposition  methods  localise  the  information 
around  functions,  while  the  object  oriented  localise  it 
around  objects.  Several  projects  have  learnt  how  this 
combination  leads  to  overwhelming  difficulty. 

The  assumption  from  above,  that  could  be  the  solution 
as  well,  would  then  be  that,  when  OOD  is  applied  this 
should  be  done  from  the  definition  of  requirements 
and  the  production  of  the  related  documentation. 
However,  this  approach  is  not  easy  to  follow.  In  fact, 
the  first  intuitive  step  in  describing  a  system  is  to  state 
the  functions  it  shall  accomplish.  At  least  user 
requirements  will  always  be  functional  oriented.  It  is 
possible,  of  course,  to  elaborate  and  express  these 
requirements  in  on  object  oriented  way,  but  the 
process  will  not  be  intuitive  and  smooth.  Furthemiorc. 
to  define  the  dynamic  behaviour  of  a  system.  OOD 
requires  the  support  of  other  methods  like  Petri  Ne  > 
and  State  Transition  Diagrams;  this  introduces 
additional  and  not  fluent  steps  into  the  developnieiit 
process. 

From  these  considerations  it  would  appear  that 
functional  methods  are  stronger  than  object  oriented 
methods  in  the  early  development  phases,  where 
errors  are  more  costly  than  the  ones  introduced  at  later 
times. 

Software  Design 

Software  Design  is  divided  in  two  steps.  Preliminary 
and  Detailed  Design.  The  former  is  the  definition  of 
the  overall  software  architecture  that  will  be  expanded 
and  detailed  in  the  latter. 

The  modem  methods  and  (partially)  tools  have  known 
big  improvements  in  the  last  decade.  It  can,  therefore, 
be  assumed  that  when  looking  at  Software  Design  as 
a  stand  alone  set  of  activities,  the  support  provided  by 
the  various  methods  can  be  considered  comparable, 
at  least  in  general  terms.  Advantages  and 
disadvantages  still  exist,  of  course,  and  depend  upon 
the  characteristics  of  the  specific  project,  but  they 
usually  compensate  each  other. 

During  a  discussion  held  to  assess  the  results  of  an 
evaluation  exercise  on  both  methods  a  developer  .said, 
may  be  a  bit  naively,  that  the  main  problem  in 
assessing  the  two  designs  was  to  tell  the  differences 
between  them.  Surprisingly  most  of  the  attendees 
agreed. 

In  addition  to  the  characteristics  of  the  system  under 
developmer.;,  another  aspect  to  be  considered  in  our 
comparison  is  the  support  to  the  various  phases  of  Ihc 
design.  In  the  preceding  paragraph  we  have 
highlighted  the  hardness  in  applying  object  oriented 
methods  in  the  requirement  analysis  and 
representation.  This  implies  that  there  is  very  little 
chance  for  software  developers  to  work  on 
requirements  genuinely  object  oriented. 

From  this  consideration  we  can  derive  that,  in  general, 
functional  oriented  methods  are  stronger  in  the  early 
stages  of  software  design,  that  is  going  from 
requirements  to  top  level  design  elements. 
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Coding 

Another  fundamental  issue  on  any  software 
development  is  the  transition  from  design  to 
implementation,  in  other  words,  the  mapping  of 
design  elements  into  programming  language 
constructs. 

Before  continuing  our  comparison  we  need  a  small 
digression  on  programming  languages. 

Ada  was  developed  in  the  early  Eighties  to  answer  the 
challenge  of  the  software  crisis.  It  was  not  specifically 
manufactured  to  suppon  object  oriented  design. 
Nevertheless,  some  of  its  features  like  data  and 
processing  abstraction,  generic  types,  packages  (that 
support  information  hiding),  have  revealed 
themselves  particularly  useful  in  implementing  object 
oriented  design. 

Although,  due  to  .several  real  time  deficiencies  (some 
of  which  arc  expected  to  be  corrected  in  ihe  9X 
revision).  Ada  is  not  considered  the  best  choice  on 
applications  with  very  stringent  real  time  constraints, 
its  diffusion  is  such  that  several  object  oriented 
variants  (eg.  HOOD)  have  been  developed 
specifically  to  support  it. 

In  the  meantime,  several  object  oriented  languages  are 
being  developed,  some  of  them  with  specific  support 
for  real  time  applications. 

Therefore,  from  one  side  we  have  an  object  based 
language  (Ada)  and  a  set  of  OOD  variants  adapted  to 
support  it.  and  from  the  other  object  oriented 
languages  specifically  developed  to  support  object 
oriented  design. 

Assuming  we  are  adopting  an  object  oriented 
language  (Ada  or  other),  we  can  certainly  conclude 
that  the  transition  from  design  to  implementation  is 
smoother  if  an  object  oriented  design  has  been 
followed. 

6.3  Testing 

Software  is  a  fundamental  and  costly  activity  in  the 
software  development  cycle.  An  accepted  figure  is 
that  up  to  the  40%  of  the  total  project  effort  lay  on 
testing. 

Two  .sets  of  inputs  are  fed  into  the  testing  process:  the 
software  configuration  (Software  Requirements, 
Software  Design  Documents,  source  code)  and  the  test 
configuration  comprising  of  test  plans  and  procedures, 
test  cases,  and  expected  results. 

It  is  important  to  note  that  the  objective  of  software 
testing  is  to  di.scover  errors  with  the  minimum  amount 
of  time  and  resources.  A  testing  exercise  should  not 
be  aimed  merely  to  demonstrate  that  the  software  is 
error  free. 

To  be  considered  successful  software  testing  must 
discover  errors  in  the  software.  As  a  consequence 
testing  demonstrates  that  the  software  appears  to  be 
working  according  to  specification. 

Testing  can  be  divided  in  two  classes:  white  box  and 
black  box  testing. 
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White  box  testing  is  a  way  to  conduct  testing  to  prove 
the  correctness  of  the  software  slmcturc,  and  that  the 
internal  functions  perform  according  to  specification. 
Black  box  testing,  concentrate  on  the  functional 
requirements  of  the  software.  It  enables  the  tester  to 
derive  sets  of  input  condition  that  should  exhaustively 
exercise  all  functional  requirements  of  a  program. 

A  typical  example  of  testing  conducted  applying  the 
black  box  approach  is  the  Formal  Acceptance  Testing 
conducted  on  the  final  software  load. 

Classic  examples  of  white-box  testing  are  the  testing 
phases  conducted  "infonnally"  on  units  and  aggregate 
of  units,  also  known  as  Unit  Testing  and  Software 
Integration  Testing. 

A  well  accepted  postulate  is  that  exhaustive  testing  is 
impossible  for  large  software  systems.  That  means 
that  no  testing  process  will  ever  lead  to  a  100  percent 
correct  program. 

From  this  consideration  we  can  evince  that  the  key 
point  for  a  successful  software  testing,  and  of  the 
associated  project,  is  modularity.  Simpler  and  well 
built  modules  designed  according  to  good  engineering 
principles,  are  easier  to  understand  and  test.  The  tested 
modules  are  then  integrated  in  more  complex  ones,  on 
which  different  types  of  testing  arc  performed.  If  the 
system  has  been  correctly  decomposed  and  the 
interfaces  properly  defined,  that  is  the  essence  of 
modularity,  then  the  software  testing  has  good 
probability  to  achieve  its  objective. 

Coming  back  to  our  comparison,  we  can  deduce  that 
the  key  for  a  successful  software  testing  lays  in  an 
excellent  design  produced  according  to  good 
engineering  principles,  with  particular  emphasis  on 
modularity.  Whether  it  is  better  that  this  design  is 
developed  according  to  a  functional  oriented  or  an 
object  oriented  methodology  is  a  marginal  and 
questionable  argument.  As  usual  pro  and  cons  on 
different  aspects  compensate  each  other. 

However,  there  is  an  aspect  where  the  functional 
methods  are  definitely  more  appropriate.  This  is  when, 
for  whatever  reason,  a  software  load  must  achieve 
partial  clearance.  We  have  already  seen  that  one  of  the 
main  effects  of  the  software  crisis  is  the  likelihood  of 
software  being  late.  In  the  light  of  thi^-  reasoning  the 
possibility  to  deliver  interim  software  releases, 
possibly  complete  but  only  partially  tested,  is  one  of 
the  options  tomitigaie  the  impact  on  the  entire  project. 
The  large  number  of  parallel  and  highly  integrated 
activities  composing  the  development  of  a  typical 
Aerospace  product  -  a  new  aircraft  for  example  - 
together  with  the  fact  that  modem  systems  are  full  of 
nice-to-have  functions,  makes  this  option  particularly 
viable  and  rather  common.  Think,  for  example,  to 
preliminary  software  versions  used  on  integration  rigs 
or  for  on-ground  aircraft  testing. 

In  these  ca.ses  functional  methods  are  considerably 
better  for  the  simple  reason  that  partial  clearance 
simply  means  to  prove  that  a  set  of  functions, 
considered  e.s.sential  for  the  purpose  of  the  specific 


software  delivery,  are  correct.  This  result  is  easier  to 
achieve  if  the  design  of  the  system,  in  addition  of  being 
modular,  is  developed  around  fuiKtions  rather  than 
objects,  as  there  should  be  fewer  modules  to  be  tested 
to  clear  each  individual  function. 

6.4  Software  Safety 

The  widespread  diffusion  of  digital  computer  systems 
makes  very  common  the  situation  of  human  life 
retying  entirely  on  software.  When  this  happens  the 
software  is  commonly  classified  safety  critical. 
Specific  methodologies,  standards,  and  procedures 
must  be  applied  in  order  to  achieve  the  necessary 
confidence  on  the  quality  of  such  softw  are  making  its 
development  much  more  expensive  (up  to  three  times) 
and  challenging  than  the  average. 

The  problems  related  to  the  development  of  safety 
critical  software  are  well  kmiwn  and  are  outside  the 
scope  of  this  paper.  However,  to  continue  our 
comparison,  we  must  provide  some  hint  on 
programming  languages  and  their  relationship  with 
safety. 

The  aim  of  the  High  Order  Languages  (HOL)  is  to 
alleviate  programmer  s  work-load  in  implementing 
composite  set  of  actions  with  single  code  statements 
or  providing  useful  but  complicated  facilities,  a  good 
example  of  the  latter  is  Ada  tasking.  While  this  is 
certainly  desirable  from  the  productivity  point  of 
view,  it  can  have  disastrous  effect  on  safety.  In  fact, 
one  area  of  concern  about  software  safety  is  the 
pos.sible  errors  introduced  by  compilers.  Any  HOL 
statement  is  automatically  translated  into  a  number  of 
simpler  intemiediate  statements  (their  number 
depending  on  the  original  statement  complexity)  and 
thereafter  into  the  object  code.  It  is  intuitive  that  the 
more  complex  the  HOL  statement  the  higher  the 
probability  to  introduce  errors  during  its 
implementation.  Another  argument  for  simplicity  of 
the  HOL  is  the  need  for  a  simple  correspondence 
between  the  source  code  and  its  compiled  version,  to 
allow  the  correctness  of  the  latter  to  be  checked. 

Due  to  their  complexity  HOL  languages  are  therefore 
not  particularly  suitable  for  the  development  of  safety 
critical  software.  Speaking  of  Ada.  to  overcome  this 
problem  different  subsets  of  the  original  language 
have  been  developed.  SPARK  is  one  of  the  most 
popular,  at  Iea.st  in  Europe.  The  leading  concept  on 
which  these  subsets  arc  based  is  to  reduce  the  compiler 
complexity  by  restricting  the  use  of  particular 
language  features.  In  SPARK  the  use  of  Ada  tasking 
is  excluded  because  of  its  high  degree  of 
non-determinism  due  to  the  extremely  complex 
interactions  between  concurrent  processes. 
Exceptions  arc  to  be  avoided  because  it  is  easier  to 
write  an  exception-free  program,  and  prove  it  to  be  .so. 
than  to  prove  that  the  corrective  actions  performed  by 
the  exception  handler  arc  appropriate  under  all 
possible  conditions. 
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Generic  units  are  to  be  avoided  because  the 
complexity  introduced  by  them  is  not  justified. 
Basically  the  problem  is  the  difficulty  to  prove  the 
correctness  of  all  instantiations  of  a  generic  unit 
All  Ada  features  requiring  dynamic  storage 
allocation  are  not  allowed.  This  includes  access 
types,  dynamically  constrained  arrays, 
discriminants  and  recursion.  Although  to  a  different 
extent  all  these  features  make  the  problem  of  verifying 
compiled  code  impossibly  difficult.  Furthennore, 
dynamic  storage  allocation  also  makes  usually 
impossible  to  establish  memory  requirements. 
Scope,  visibility,  and  overloading  niles  are 
remarkably  complicated  and  confuse  verification 
quite  unnecessarily.  To  simplify  this  aspect 
overloading,  block  statements,  and  use  clause  are 
prohibited,  while  the  use  of  renaming  declarations 
is  restricted. 

A  numberof  less  important  Ada  features,  which  imply 
a  penalty  in  complexity  with  no  substantial  benefits 
for  programmers  are  also  banned  by  SPARK. 

From  above  we  can  see  that  most  of  the  features  that 
make  Ada  so  attractive  for  implementing  object 
oriented  designs  are  forbidden,  or  highly  undesirable, 
for  safety  critical  applications.  The  same  applies  for 
any  other  HOL.  From  this  we  can  derive  that  also  OOD 
methods  are  not  particularly  convenient  for  safety 
critical  software  development.  This  doesn’t  mean 
their  use  is  detrimental  but  simply  that  most  of  the 
claimed  reasons  that  make  OOD  "the  solution"  for  the 
software  crisis,  cease  to  exist  in  safety  critical 
applications.  In  this  field  the  "old  good"  ^nctional 
methods  can  therefore  still  be  considered  the  best 
choice.  Of  course,  in  a  project  involving  the 
development  of  both  safety  critical  and  ordinary 
software  the  application  of  different  methods  can  be 
impracticable.  In  this  case  the  choice  should  be  driven 
by  the  characteristics  of  the  project  itself. 

6.5  Maintainability 

Software  maintenance  is  defined  as  the  process  to 
modify  existing  software  leaving  its  main  functions 
intact. 

A  reasonable  percentage  (less  than  40%)  of  redesign 
and  redevelopment  of  new  code  can  still  be  considered 
maintenance.  Above  this  figure  we  must  speak  of  new 
development. 

Software  maintenance  can  take  the  fomi  of  software 
update  or  repair.  Software  update  is  when  the 
functionality  of  the  .software  is  changed,  usually 
because  of  changes  to  requirements  or  system 
architecture.  Software  repair  leaves  the  original 
software  functions  intact. 

Maintainability  is  the  quality  factor  that  indicates  how 
easy  it  is  to  maintain  the  software,  that  is  to  modify  it. 
It  can  be  achieved  by  applying  proper  engineering 
criteria  like  self-descriptiveness  consistency, 
semplicity,  and  modularity.  The  first  three  depend 


upon  the  programming  language  chosen 
(self-descriptiveness),  the  standards  apfdied 
(consisteiKy).  and  the  working  practice  (simplicity). 
In  any  case  they  can  be  considered  secondary  if 
compared  with  modularity.  They  are.  in  fact,  related 
to  the  description,  rather  than  to  the  actual  quality  of 
the  software. 

Modularity  is  therefore  tire  only  property  having 
straightforward  impact  on  software  maintainability. 

Design  methods  and  programming  languages  have 
severe  impact  on  modularity.  Although  all  modem 
methods  enforce  good  engineering  principles  that 
include  modularity,  the  leading  principles  of  object 
oriented  approaches  (information  hiding,  abstraction, 
localisation)  are  essentially  the  same  that  fonn  the 
basisof  a  modulardesign.  OOD  methods  can  therefore 
be  considered  inherently  more  appropriate  to  support 
modularity.  This  conclusion  is  strengthened  by  tlK 
fact  that  object  oriented  languages  support  modularity 
at  a  greater  extent  than  any  other  HOL,  and  that  the 
use  of  OOD  methods  in  conjutKtion  with  these 
languages  has  proven  to  be  quite  advantageous. 

6.6  Relationship  with  DOD-STD-2167 

DOD- STD-2167  was  originally  issued  in  1985  and  is 
a  framewoik  document  providing  guidelines  for  the 
management  and  documentation  covering  the 
development  of  military  guidance  and  control 
software.  While  the  corresponding  civil  standard 
RTCA-DO/I78  only  addresses  the  certification  of 
software  as  part  of  a  system.  DOD- STD-2 1 67  covers 
the  situation  where  the  software  is  delivered  as  a 
stand-alone  product. 

To  take  into  account  comments  received  following  the 
first  period  of  application  -  and  to  resolve  the  major 
incompatibilities  with  the  use  of  Ada  and  the 
progressing  software  engineering  technologies  -  a 
new  revision  of  2167  was  issued  in  1988. 

Some  strict  interpretations  of  the  original 
DOD-STD-2167  requirements  support  functional 
decomposition  rather  than  object  oriented  design.  The 
2167  " waterfall"  life  cycle  model  -  with  its  stringent 
requirement  with  respect  to  beginnings  and  endings 
of  each  life  cycle  phases  -  is  not  particularly  suitable 
for  supporting  OOD.  The  concept  of  "code  a  little,  test 
a  little"  is  difficult  to  apply. 

The  phase  in  which  this  aspect  is  most  noticeable  is 
the  software  design.  DOD-STD-2167  splits  it  into 
Preliminary  and  Detailed  Design,  separated  by  the 
Preliminary  Design  Review  (PDR).  In  OOD  this 
separation  is  somehow  artificial  and  introduces 
additional  workload  and  in  some  cases  can  be 
deleterious. 

This  partial  incompatibility  of  EXDD- STD-2 167  with 
object  oriented  can  be  explained  with  the  fact  that  in 
1985  OOD  was  not  enough  widespread  to  influence 
the  well  established  confidence  on  traditional 
methods. 
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Neveitheless,  having  acknowledged  the  need  to  cope 
with  the  outstanding  development  of  software 
engineering  discipline.  DOD-STD-2I67A  has 
relaxed  some  too  stringent  requirements  and  has 
become  "method  independent".  This  has  conceded 
significant  flexibility  in  preparing  dedicated  project 
standards,  allowing  to  apply  virtually  all 
methodologies. 

Therefore,  the  claimed  incompatibility  between 
object  oriented  approaches  and  military  standards  is 
not  a  problem  any  more. 
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For  the  benefit  of  those  who  are  used  to  read  only  the 
Introduction  and/or  the  Conclusion  paragraphs  of  a 
paper  we  briefly  summarise  the  outcome  of  the 
analysis  performed  on  the  chosen  aspects  of  a  typical 
software  project. 

-  Functional  oriented  methods  are  stronger  in  the 
early  development  phases  (System  and  Software 
Requirements  Analysis)  where  errors  tend  to  be 
more  costly  (See  paragraph  6.2  Software 
Requirements). 

-  Functional  oriented  methods  are  stronger  also  in  the 
early  stages  of  Software  Design,  providing  a  better 
support  to  the  transition  from  requirements  to  top 
level  design  elements  (See  paragraph  6.2  Software 
Design). 

-  Adopting  an  object  oriented  language  (Ada  or 
other),  OOD  methods  ensure  a  smoother  transition 
from  design  to  implementation.  (See  paragraph  6.2 
Coding). 

-  The  support  provided  by  the  methods  to  the  testing 
activities  is  comparable,  but  Functional  methods 
prove  to  be  considerably  better  to  support  partial 
clearance  (See  paragraph  6.3). 

-  In  safety  critical  applications  most  of  the  reasons 
that  according  to  OOD  promoters  make  OOD  "the 
solution"  for  the  software  crisis,  cease  to  exist  (See 
paragraph  6.4). 

-  OOD  methods  can  be  considered  inherently  more 
appropriate  to  support  maintainability.  (See 
paragraph  6.5). 

-  The  incompatibility  between  Object  Oriented 
approaches  and  military  standards,  primarily 
DOD-STD-2167,  i  s  not  a  problem  any  more  (Sec 
paragraph  6.6). 

Having  analysed  the  primary  aspects  relevant  to  the 
development  of  a  typical  real  time  softwa-e  system  we 
are  now  in  the  position  to  propose  a  possible  set  of 
subjective  answers  to  the  questions  put  forth  in  the 
Introduction  paragraph. 

Based  on  my  personal  experience  I  believe  that  the 


answer  to  the  first  question  is  NO:  in  real  time 
applications.  OOD  methods  have  not  maintained  the 
expectations.  In  the  second  half  of  Eighties  OOD  were 
considered  the  only  viable  option  for  future  projects. 
Their  shortcomings  were  justified  with  lack  of 
experience,  human  innate  resistance  to  change,  and 
poor  tool  support.  After  7-8  years  the  situation  is 
basically  the  same.  OOD  is  not  spread  as  expected, 
the  same  objections  are  raised,  and  OOD  promoters 
provide  the  same  answer  of  7-8  years  ago. 

The  answer  to  the  second  question  is  YES.  Functional 
methods  can  still  support  large  real  lime  system 
development.  At  least  until  somebody  will  be  able  to 
provide  an  alternative  "magical  solution". 

To  conclude  the  paper.  1  wish  to  summarise  the 
outcome  of  the  comparison  in  a  few  points; 

i)  Somehow  Functional  methods  have  allowed  the 
Software  Engineering  community  to  survive  - 
even  though  with  severe  problems  -  to  the 
software  crisis. 

ii)  The  alternatives  to  Functional  methods  have  not 
proven  to  be  "the  solution".  Some  of  them  may 
be  comparable  or  even  slightly  better  but  not  to 
the  extent  necessary  to  definitively  remove  the 
causes  of  the  crisis. 

iii)  The  main  innovative  and  advantageous  features 
of  OOD  methods  are  not  fully  exploited  in  real 
time  systems. 

iv)  The  design  method  and  tot)l  is  only  a  part  of  the 
development  environment.  Programming 
languages,  testing  tools  and  strategy. 
Configuration  Management  tools  and  practice  - 
complemented  by  appropriate  standards  and 
procedures  -  are  other  fundamental  issues  for  any 
software  project.  These  methods  and  tools  cannot 
be  considered  in  isolation  and  the  choice  of  each 
of  them  must  be  based  on  solid  and  consistent 
technical  arguments. 

Finally,  let  me  say  the  last  word: 

The  existence  of  the  software  crisis  cannot  be  denied 
and  is  due  to  tangible  causes.  Ncverthcle.s.s,  it  has 
become  an  easy  excuse  to  justify  too  many  fiascos  due 
instead  to  errors  in  understanding  and  managing  the 
project  needs,  characteristics,  and  purpose. 

At  any  rate  for  real  lime  systems,  as  for  any  other 
applications,  the  key  to  success  does  not  lay  on 
Functions  or  on  Objects,  but  in  avoiding  artificial  and 
senseless  solution  based  on  purely  commercial  and 
political  speculations.  Nobody  is  so  naive  to  think  that 
politics  and  business  can  be  ignored,  but  they  must  be 
somehow  limited  allowing  enough  space  to  apply 
rational  Software  Engineering  principles  and 
practices. 


Discussion 


Queslioii  CJL.  BENJAMIN 

In  your  presenUMkw,  you  discussed  die  strengbs  and  weaknesses  of  fiinctiooal  methods  and  OOD  methods.  Do  you 
leoommend  that  work  be  done  usmg  both  afiproacfaes?  Is  that  possdile? 

Reply 

I  do  not  consider  viable  the  solution  of  applying  the  2  methods.  I  suspect  that  this  will  mean  a  sum  of  the  shortcomings 
of  both  methods,  giving  no  real  advantage.  I  do  believe  that  the  choice  of  a  consistent  system  de vetopment  enviroonent, 
complonenied  by  appropriate  standards  and  procedures,  is  the  key  for  a  sucessful  project,  irrespective  of  functioos  or 
obje^. 

Question  K.  ROSE 

I  have  2  questions  regarding  OCX)  Sc.  Ada.  but  first  I  have  some  comments.  The  first  OO  language  was  Simula  67. 
developped  in  Norway  based  on  work  at  the  Norwegian  Defense  Research  Establishment  in  the  early  60s.  so  OO  is 
nothing  new.  Simula  has  inspited  the  development  of  Smalltalk  and  C^.  Simula  support  concurrency  but  is  not  suited 
for  Real  Time  because  of  inefficient  memory  management  techniques.  The  ada  designers,  well  familhr  with  Simula,  for 
that  reason,  as  staled  in  the  rationale  for  the  Ada  design,  cbose  not  to  make  Ada  an  OOL.  C-4-V  has  knei  proven  that  it  is 
possible  to  develop  an  efficient  OOL  suitable  for  RT  applkations.  I  find  it  strange  to  perform  an  OOD  aind 
implementation  in  a  functional  language  (Ada). 

To  what  extent  do  you  believe  that  your  conclusions  are  influenced  by  Ada's  limitations  regarding  both  RT  and  OO?  Do 
you  believe  that  Ada  9X  will  solve  Ada's  problems  regarding  OO  and  concurrency/RT? 

Reply 

I  stated  that  Ada  is  not  an  Objea  Oriented  language,  but  an  olqect-based  language.  I  do  believe,  however,  that  several 
Ada  features  are  more  than  desirable  to  siqiport  OOD.  Indeed  the  me  of  Ada  with  OOD  is  widespread  enough  not  to 
consider  it  ’strange”  to  apply  this  approach.  The  proliferation  of  OOD  variants  to  support  Ada  ebforces  my  ofwion. 

In  answering  the  questions.  I  want  to  make  a  small  remark  concerning  the  so  called  ’Ada  limitations  regarding  OO’.  It  is 
not  posiible  mid  convenient  to  hide  the  OOD  limitations  of  OOD  in  real  time  systems  development  (aknowledged  by  the 
software  engineering  commnity)  with  claimed  limitations  of  the  HOL.  The  answer  is  then  NO,  the  Ada  limitations  did 
not  influence  my  conclusions,  I  do  believe  that  OCX)  is  not  ’the  solution’  to  the  software  crisis  on  real  time  systems. 

I  am  not  with  Ada  9X,  but  the  claims  are  that  it  will  solve  several  Ada  real  time  limitations.  I  did  not  hear 

anything  about  OO  support  so  I  do'nt  know. 
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The  goal  of  this  article  is  to  sketch  a 
first  evaluation  after  almost  four  year 
usage  of  the  Hood  methodology  in  the 
context  of  Ada  real  time  software 
systems . 

For  this  purpose,  it  is  made  up  of  four 
parts : 

-  First,  we  will  give  a  brief  outline 
of  Hood  methodology 

~  Secondly  we  quickly  sketch  out  four 
years  of  Hood  usage. 

-  Thirdly,  we  will  summarize  the  main 
lessons  learnt  throughout  this 
experience. 

-  Fourthly,  we  will  outline  some 
directions  useful  to  follow-up  in  the 
future. 

1  IMTRODDCTIOII 

The  Hierarchical  Object  Oriented  Design 
(HOOD)  is  an  architectural  (or 
preliminary)  design  method  defined  for 
the  intention  of  the  European  Space 
Agency  (ESA) .  This  method  is  used  in 
several  space  software  development  such 
as  the  launcher  Ariane  Vth,  Columbus  or 
the  Spot  3th  satellite. 

2  _ hood gmdiigma 


processes,  functions,  routines  or 
program  pieces  but  well-formed  objects 
-  ie  consistent  agregate  of  data  and 
related  operations  referring  to  domain 
problem  entities  -. 

For  example,  if  an  aircraft  monitoring 
coaputer  deals  with  the  fuel  level  of 
the  tank  it  isn't  surprising  that  a 
Fuel_tank  object  appears  in  the  design 
which  holds  the  fuel  level  as  an 
internal  attribute  and  provides  two 
services  -set  and  read-. 


Provided 

h^erface  j 

\  ^ 

^  ^  ^ue(  tank  ~ 


Internal 

Attribules 


This  orientation  isn't  a  spineless 
accommodation  with  the  mode  buzzwords 
but  the  belief  that  object  oriented 
software  are  more  resistent  to  impact 
of  evolutions  and  specification 
changes. 


This  part  deals  with  the  most 
significant  features  of  the  Hood  method 
and  its  technical  and  institutional 
environment . 

2.1  The  Object  Orientation 

The  Main  pillar  of  the  Hood  method  is 
its  Object  Orientation. 

This  statement  means  that  the  basic 
components  of  a  software  system  aren't 


2.2  Top-Down  Breaking-Down 

The  second  pillar  of  the  Hood  method  is 
its  Top-Down  Hierarchical  Orientation. 

For  example,  if  a  helicopter  monitoring 
computer  copes  with  different 
information  concerning  disflay  units, 
rotor,  engines  ,  ...  ir  may  be 
interesting  to  hold  this  information  in 
an  upper  abstraction  "The_Aircraf t "  in 
order  to  manage  the  complexity . 
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This  second  point  is  a  very 
controversial  one.  Is  Object 
orientation  consistent  with  top-down 
approach?  Does  Object  Oriented  Design 
process  have  to  be  Bottom-Up  oriented 
as  B.  Meyer  and  other  Object  "gurus" 
recommend  it? 


Start  I - 


^  ►{start 


d_bylink 


2 . 3  Tbe  Rood  Rotation 

The  HOOD  method  assumes  that  a  software 
system  may  be  designed  as  a  collection 
of  objects  interrelated  through  two 
relationships : 

The  "u3ea_service3_p/"  relation-ship 
and  the  "l3_coinpo3ed_of'"  relationship. 


Control  Flow 


Data  Flow 


Read_Power_Available 

Control_Engine_Heai1h 


The  Aircraft  includea  (or  la  the  Parent  of) 
the  Computer  and  the  Turbo_EnglneGroup. 
The  Turbo_Englne_Group  la  a  child  object. 
AlrereftStart  la  implefflentad_by 
Computer.Start 


Fuel  Tank 


Set_Level 
Read  Level 


OnBoard_Coniputer 
used  services 
provided  by  Fue(_Tank 

The  " use_services _jjrovided_by" 
relationship  allows  to  model  the  action 
of  an  object  (client)  on  an  other 
object  (server) . 

The  " i3_inade_up_of”  relationship  allows 
to  model  probably  the  most  basic 
cognitive  mechanism 

These  two  relationships  provide  a 
consistent  frame  to  model  large  real¬ 
time  systems  satisfying  reliability  and 
operational  long  lifetime  recjuirements . 

Hood  distinguishes  two  Itinds  of 
objects:  Non  Terminal  and  Terminal 
Objects.  Obviously,  Not  Terminal 
objects  have  child  objects.  Every 


2 . 4  System  and  Class  Spaces 

As  opposed  to  Object  Oriented  Languages 
that  mix  classes  and  objects 
(instances)  unseparatly,  HOOD  method 
splits  distinctly  software  products 
according  to  two  spaces:  Design  space 
and  Class  space. 

On  one  hand,  the  Design  Space  holds 
operational  software  or  parts  of 
operational  software. 

On  the  other  hand,  the  Class  space 
collects  reusable  software  components. 

For  example,  if  an  helicopter 
monitoring  computer  copes  with  several 
objects  designed  in  the  same  way  such 
as  Fuel_Tank  and  Oil_Tank  it  is 
interesting  to  catch  the  commonalities 
of  these  two  objects  into  a  reusable 
frame  ""Tank"  located  in  the  Class  Space 
while  instance  objects  named  FuelTank 
and  Oil_Tank  are  located  in  the  Design 
Space  as  Terminal  Objects. 
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These  two  spaces  are  afterward  linked 
by  the  Instantiation  mechanlsn. 


In  fact.  Hood  method  gives  here  a 
practical  consistency  to  the  1968-old 
Mac  Ilroy  (i]  views  about  the  software 
crisis  and  the  industrial  way  to  get 
out  of  the  software  proto-history. 


object  will  be  definitively  iaipleiiiented 
(anonyBK>us  object)  or  instantiate  from 
a  class  (instance  object)  during  detail 
design  and  coding  phases . 


End  of  Architectural  Design  Phase 


Here,  Hood  design  process  provides  a 
technical  consistent  boundary  between 
preliminary  (or  architectural)  design 
and  detail  design.  Preliminary  Design 
deals  with  object  identification  and 
external  specification  of  terminal 
objects  while  Detail  Design  deals  with 
terminal  objects  implementation. 

He  consider  that  a  terminal  object 
generally  corresponds  to  a  package 
sized  from  100  to  500  Ada  lines. 

2 . 6  The  Hood  User  Group 


2 . 5  The  Hood  Process 

The  HOOD  Method  is  not  at  all  a 
notation  (Poor  method  such  as  a  method 
that  is  reduced  to  a  notation) . 


Like  Ada  language  is  supported  by  the 
US  DOD,  the  HOOD  method  is  backed  by 
ESA.  Hood  method  is  the  property  of  its 
users  joined  in  the  Hood  User  Group 


(HUG)  . 


The  Hood  method  recommends  an  iterative 
process  based  on  basic  design  steps . 

This  basic  design  step,  inspired  from 
Abbott  (zl,  begins  with  the  statement 
of  the  problem  that  the  system  (resp. 
the  object)  has  to  solve  and  ends  with 
the  external  specifications  of  child 
objects . 

Child  objects  may  be  non  terminal 
object,  and  the  basic  design  step 
resumes  for  these  objects,  or  terminal 
objects.  In  this  second  case,  terminal 


The  HOG  collects  user  observations  and 
defines  method  evolutions.  The  HUG 
garanties  stability  for  Hood  tool 
vendors  concerning  their  investements . 

The  Hood  method  is  described  through 
Hood  Manuals  edited  by  the  HUG. 

The  Hood  Reference  Manual. Its  latest 
issue  is  the  3.1.1  issue  released  in 
july  1992  and  co-published  in  about  may 
1993  by  Prentice-Hall  and  Masson.  And 
the  Hood  User  Manual,  its  issue  3.1 
revised  at  the  moment  by  the  HUG. 
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a  HOOP  la  Action 

Hood  Mthod  has  boon  used  on  several 
navy  (3]  and  space  projects.  This 
chapter  presents  Hood  projects  which 
are  in  the  authors'  scope. 

3 . 1  Hood  and  tbe  TIGBR  Helicopter 
Frograit 

The  TIGER  helicopter  is  a  German-French 
military  '  ilicoptec  under  development 
with  two  main  aiissions:  Anti-Tank 
Mission  (the  Tiger  :PAH2/HAC 
helicopter)  and  Support  and  Protection 
Mission  (the  (Serfaut:  HAP  helicopter). 
Eurocopter  has  the  global 
responsibility  of  this  developsient . 

Concerning  Avionics  software, 
Eurocopter/France  is  in  charge  of  the 
Mission  avionic  computers:  The  embedded 
software  of  Mission. Computer  and  Symbol 
Generator  (MCSG)  concerning  the 
PAH2/HAC  mission  and  the  software 
Armament  Computer  and  Symbol  Generator 
(ACSG/CDD)  concerning  the  HAP  mission. 

3.1.1  The  TIGBR  Mission  Coaq>uters 

MCSG  and  ACSG/CDO  have  been  developped 
since  1990  at  Marignane  by  joint  teams 
of  Eurocopter-F ranee  and  Steria,  as 
partner. 

By  1990,  After  evaluation,  HOOD  has 
been  selected  as  Preliminary  Design 
Method.  Four  major  versions  have  been 
released  and  the  following  are  under 
development . 

The  size  of  the  early  versions  is  close 
to  50_000  Ada  lines  and  the  latest  ones 
approach  70_000  Ada  lines. 

Time  constraints  are  severe  enough 
(time  base:  20  milliseconds) . 

On  the  other  hand,  required  reliability 
is  high  (Test  programs  multiply  per  3 
the  number  of  Ada  lines  developped  in 
the  context  of  the  MCSG  and  the 
ACSG/CDD) . 

3.1.2  Other  Rurocopter  Avionic 
Projects 

Next  to  the  MCSG  and  ACSG,  Eurocopter 
France,  in  partnership  with  Steria, 
developes  several  other  avionic 
softwa re . 


Some  of  them  are  in  the  frcime  of  the 
Tiger  program,  such  as 

-  Dolphin  demonstrator  for  validation 
of  AC3G  which  is  a  weapon  control 
system  (3rd  Generation  Anti-Tank 
missile) intended  for  the  Tiger 
helicopter.  This  software  involves 
15_000  Ada  lines. 

-  PUMA-PVS  which  is  a  desxjnstrator  for 
validation  of  a  Pilot  Visionic  System 
intended  for  the  Tiger  helicopters. 
This  software  involves  60_000  Ada 
lines. 

Others  are  Eurocopter  specific  systems 
under  development  such  as 

-  ACSR  which  is  a  rotor  vibration 
control  system.  This  software  involves 
10_000  Ada  lines. 

-  ARMS  which  is  a  recording  and 
monitoring  system  of  helicopter  health 
and  usage.  It  experiments  the  Modular 
Avionics  technology  and  will  provide, 
in  the  future,  maintenance  on 
condition. 

This  software  involves  22_000  Ada 
lines. 

-  PHL  which  is  an  engine  monitoring 
system  designed  for  light-weight  and 
medium  helicopters. 

This  software  involves  20_000  Ada 
lines. 

3.2  Other  Projects  managed  by 
Steria 

Independently,  Steria  developes  other 
large  Ada  software  with  the  same 
methodology . 

3.2.1  Air  Traffic  Control  System 

In  the  Air  Traffic  Control  Domain, 
Steria  is  in  charge  of  the  development 
of  a  subsystem  of  CAUTRA  (Controle 
Automatique  du  Trafic  Aerien) .  This 
subsystem  monitors  the  traffic  control 
system  in  its  whole. This  software 
involves  25_000  Ada  lines. 

3.2.2  SMER  Crew  Training 
simulators 


In  order  to  train  the  SNLE  submarine 
crews,  the  French  DGA  has  designed 
several  simulators  (Soument  Project) . 


Stasia  la  in  charga  of  the  davalopnent 
of  one  of  thaaa  sloiuiatora  (Soument- 
SPP)  ualng  the  Hood  method.  This 
software  Involves  4S_000  Ada  lines. 
Other  simulators  are  developped  with 
the  Hood  method. 
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4  Possibilities,  Limitations 
and  Deslcables  Improvements 


Concerning  GDS  project,  productivity 
figures  are  over  50  Ada  line  per  day 
from  preliminary  design  to  integration. 

4 . 2  Mastering  Complexity 

The  main  lesson  that  we  have  learnt 
from  our  experience  is  that  the  Hood 
method  is  very  powerful  means  to  master 
complexity. 

In  spite  of  raised  objections  and  true 
undesirable  secondary  effects,  we  think 
that  this  power  is  due  to  the  top  down 
hierarchical  orientation  of  Hood. 


This  aspect  has  been  a  key  factor  to 
master  the  complexity. 
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After  Interfaces  and  behaviour 
are  specified,  each  object  may  be 
independently  designed. 


4.1  Msstsslng  Projects 

It  is  generally  difficult  to  determine 
the  keys  of  any  success.  It  depends  on 
the  teams,  the  development  tools,  the 
methodclogy  and  a  lot  of  technical  and 
human  factors 

With  a  background  of  almost  four  years, 
we  could  state  that  Hood  methodology 
assits  project  managers  efficiently  in 
their  jobs.  We  have  been  able  to 
release  conplex  sofware  with  the 
required  quality  on  time. 

This  result  has  been  reached  with 
different  teams,  different  Ada  and  Hood 
tools  and  within  different  domains. 

Productivity  figures  depend  directly  on 

-  the  complexity  of  the  production  line 
(Host,  Emulation  environment.  Software 
Test  Bench) . 

-  the  required  safety  and  test  effort 


We  have  been  able  to  put  subteams  on 
different  parts  of  design  allowing 
parallel  developments. 

4.3  Dealing  with  Distribution 

In  order  to  deal  with  multi-processor 
architectures  and  distribution 
problems.  Hood  has  introduced  the 
Virtual  Node  concept .  A  virtual  Node  is 
a  software  piece  able  to  be  allocate  to 
a  processor.  So,  a  distributed  software 
system  is  a  virtual  node  network  which 
has  to  meet  a  hardware  system  that  is  a 
physical  node  network. 

Unfortunatly, this  approach  which  is 
very  attractive  is  not  really  efficient 
In  fact,  inter  process  exchanges  are 
very  sensitive  to  the  hardware 
architecture.  Local  and  remote 
exchanges  do  not  have  the  same 
performances  and  temporal  behaviour 
depends  on  processor  allocation. 
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for  example,  the  temporal  behaviour  of 
the  ayetem  may  be  very  different  if  NVl 
and  NV2  are  put  together  or  not  on  the 
processor . . 

More,  Virtual  Node  has  no  specific 
equivalent  in  Ada83. 

So,  we  have  discarded,  for  the  moment, 
the  use  of  Virtual  Nodes  about  the 
design  of  multi-processor  applications. 
(Tiger  and  Gerfaut  computers  are  multi¬ 
processor  computers) .  We  are  waiting 
for  Ada9X  partitions. 

MifflUS  13S3 
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For  example,  ACSG  software  is  designed 
as  two  Ada  Nodes  BIM  (Bus  Interface 
Module)  and  DPM  (Data  Processing 
Module)  mapped  in  two  physical 
processors .  DPM  and  BIM  Role, 
synchronisations  and  communications 
between  Ada  programs  BIM  and  DPM  are 
fully  specified  before  the  design. 

4.4  Dealing  with  Real-Time 
Aspects 


Concerning  Real-Time  aspects,  the  Hood 
method  provides  several  features  such 
as  active  objects  which  deal  with 
parallel  evolutions  and  constrained 
operations  which  deal  with  cooperation 
between  active  objects. 

But  it  is  obvious  that  these  features 
are  insufficient  in  managing  dy^^unic 
views  of  the  solution  and  Hood  is  not 
fully  real  time  orientated. 

Our  experience  shows  this  is  not  really 
a  major  drawbaclc.  In  fact,  it  is 
possible  to  add  some  guidelines  such 
as  recommendations  provided  by  H  Gomaa 
[4],  R.J.A.  Buhr  [5]  or  Nielsen  and 
Shumate  [f]  and  a  dynamic  behaviour 
formalism  desciption  such  as  SDL[7), 
GRAFCETta)  or  STATECHARTS  (9].  These 
useful  additions  are  compliant  with  the 
process  frame  recommended  by  Hood  and 
may  be  added  into  the  Hood  User  Manual. 

For  example,  at  the  processor  level,  we 
have  introduced  a  specific  activity 
•■elated  to  the  management  of 
asynchroneous  events  and  time 
constraint  services. 


The  goal  of  this  activity  is  to  design 
the  real  time  architecture  of  the 
sof twa re . 

The  processor  is  a  shared  resource  for 
tasks,  so  the  processor  level  is  the 
right  level  to  tackle  tasking 
architecture.  At  lower  levels  this 
activity  would  be  too  late  and  without 
global  vision. 

This  activity  aims  to  define: 
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An  on-9oin9  study  pointing  out  these 
difficulties  has  been  ordered  by  ESA 
from  a  team  led  by  STERIA. 

S  Challenges 

5 . 1  Hood  and  Inheritance 

As  already  described.  Class  space  is 
the  reusability  context.  Presently, 
this  reusability  is  fully  based  on  the 
abstract  data  type  and  the  genericity 
concepts  inherited  from  Ada. 

Design  Space 

or 


Is  inheritance  a  key  concept  to 
reusability?  Probably,  yes. 
Unfortunately,  due  to  its  origin  as  a 
Ada  Design  method.  Hood  method  does  not 
deal  with  inheritance. 

Despite  its  capabilities,  this  lack  may 
become  a  handicap  in  the  future. 

Several  ways  are  forseen.  Our  feeling 
is  that  the  Hood  way  towards 
inheritance  must  not  imitate  Object 
Language  facilities  but  maintain  a 
strict  separation  of  concerns.  -  No 
change  in  the  Design  Space  which  is  the 
system  maker  workshop. 

-  Including  a  "Generalization/ 
Specialization"  relationship  at  the 
Class  Space  level  conceived  as  a 
laboratory  where  software  cong>onents 
are  elaborated,  classified  and 
improved.  Class  space  is,  with  this 
policy,  a  reusable  software  component 
repository . 


5 . 2  Bood  and  non  Ada  Target 
Languages 

Hood  is  a  design  aiethod  and  it  is  not 
desirable  that  its  fate  should  be  bound 
to  a  particular  programming  language. 

He  are  conviced  chat  Ada  is  the 
language  best  adapted  to  programming  in 
large . 

But  someone  may  have  another  opinion 
and  Hood  muse  be  able  to  address  other 
programming  languages,  C++  for  example. 

5.3  Dynamic  Description 

Probably,  Hood  needs  a  normalized  way, 
validated  by  HRM  rules  and  HUM 
guidelines,  Co  describe  dynamic 
behaviour  of  software  systems  and 
objects.  Our  feeling  is  this  formalism 
must  be  graphical  and  easy  to  use.  SDL, 
Grafcet  or  Statecharts  are,  in  our 
opinion,  are  good  candidates .  Other 
authors  recommend  Petri  Nets  [12] . 

And  certainly,  the  main  difficulty 
about  this  issue  is  reaching  a 
consensus  between  Hood  users  who  are 
generally  a  very  imaginative 
population . 
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-  the  optioHin  riumber  of  tasks  necessary 
for  fitting  teiig>oral.  and  functional 
requireswnts,  hardware  constraints  and 
the  task  priorities. 

-  the  type  of  theso  tasks  (periodic, 
aperiodic,  sporadic,  . . . ) . 

-  the  interface  of  these  tasks 
(synchronisation,  conmunication) . 

-  the  priority  of  these  tasks. 


This  tasking  architect uie  is  afterwards 
cashed  on  the  object  architecture.  This 
activity  allow;,  a  true  management  of 
time  constraints  and  is  consistent  with 
the  Rate  Monotonic  Analysis  Ciol . 

4.S  Bood  and  Traceability 

The  Hood  process  suggests  a  very  simple 
and  efficient  mean  to  maintain  the 
traceability  of  requirements  through 
the  design  process. 


At  every  basic  design  step  a 
requirement  list  may  be  allocated. 

These  requirements  are  the  requirements 
that  the  object  under  design  has  to 
satisfy. 
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After  the  child  object  b'-ea.-;  down  a 
traceability  matrix  which  states  the 
contribution  of  each  child  to  the 
sat isf ication  of  each  requirement. 

4.6  Hood  and  Documentation 

Pro. iding  a  design  documentation  such 
as  DO'r  216?  PSDD  and  SDD  which  is 
readable  and  consistent  with  Ada 
sources  is  a  requirement  that  may  lead 
to  extreme  .ffort. 

Hood  tools  provide  documentation 
facilities.  Used  without  predefined 
strategy  they  provide  boring, 
unreadable  and  endless  reports. In  fact, 
these  documentation  facilities  need 
associated  guidelines  in  order  to 
pr  duce  a  readable  and  efficient 
documentation  [n]  . 

A  lot  of  information  collected  during 
the  Hood  design  process  such  as 
“informal  strategy  of  solution"  or 
"Design  Choice  Justif  icat  iv,tis"  do  not 
have  an  equivalent  in  DOD  PSDD  and 
state  Hood  documentation  as  a 
maintenance  oriented  docunentat ion 

4.6  Hood,  Ada  Code  Extraction  and 
Kaintenance 

As  Hood  design  oupu*"  Hood  tools  may 
provide  Aaa  Skelet^  At''hitecture 
consistent  with  Ada  extraction  rules. 
Generated  Ada  code  is  run  time 
efficient  and  giobaly  constitent  w  ■ 
Hood  principles. 

But  the  lack  of  integration  between 
APSEs  and  Hood  tools  has  caused  some 
heaviness  concerning  the  maintenance 
phase . 
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I.  BACKGROUND 

The  Air  Force  Avionics  Laboratory  has  sponsored 
several  efforts  to  increase  the  accuracy  of  aircraft 
navigation  functions  while  decreasing  crew  workload 
through  the  application  of  intelligent  systems.  Two 
such  efforts  were  the  Adaptive  Tactical  Navigation 
(ATN)  System  and  the  Autonomous  Fixtaking 
Management  (AFM)  system,  which  were  both 
awarded  to  The  Analytic  Sciences  Corporation 
(TASC).  An  intelligent  system  to  aid  the  pilot  with 
navigation  functions  was  developed  under  the  ATN 
program.  This  system  incorporated  real-time 
knowledge  base  software  to  manage  the  tactical 
navigation  moding,  fault  tolerance,  and  pilot  auLng  to 
provide  a  robust  navigation  prototype  for  the  next 
generation  fighter  aircraft.  The  ATN  prograi  i 
highlighted  the  aircraft  weapons  officer's  heavy 
workload  associated  with  the  location  and 
identifleation  of  fixpoints  to  update  and  verify  the 
accuracy  of  the  navigation  system.  With  this  problc  -n 
in  mind,  it  was  determined  that  an  intelligent  system 
was  needed  to  automatically  locate,  image,  and 
identify  fixpoints  and  update  the  navigation  solution. 

The  AFM  System  was  developed  to  prove  the 
feasibility  of  autonuted  navigation  updates  using 
UKtical  sensors  and  existing  mission  data  processing 
systems.  Several  technologies  developed  under  ATN 
were  incorporated  into  the  AFM  system  including  a 
proven  simulation  of  the  navigation  sensors, 
controllers,  and  mission  planning  and  management 
software.  Autonution  of  human  fixtaking  activity 
required  integration  of  several  emerging  technologies 
including  a  real-time  data  fusion  architecture,  neural 
network  and  heuristic  aulotiuitic  recognition 
algorithms,  and  associative  memories  to  retrieve 
Sxpoints  Cram  on-bosid  databases.  Integration  of 
these  diverse  technologies  was  simplified  by  the 
employment  of  an  object-oriented  software 
development  approach  and  real-time  control  system. 


2.  INTRODUCTION 

The  Autonomous  Fixtaking  Management  (AFM) 
pn^ram's  goal  was  to  develop  and  demonstrate  an 
automated  aircraft  navigation  system  which  would  not 
only  reduce  the  crew  navigation  workload  burden,  but 
could  also  be  used  as  a  backup  to  the  Global 
Positioning  System  (GPS).  The  AFM  system 
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matched  fixpoint  images  from  on-board  databases  to 
imagery  acquired  through  Synthetic  Aperture  Radar 
(SAR)  and  Electro-Optical  (EG)  sensors  to  deuirminc 
the  vehicle's  position.  The  AFM  system  eliminates 
the  requirement  for  the  workload  intensive  process  of 
manual  fixtaking.  This  was  accomplished  by 
automating  the  activity  of  a  tactical  navigator  in 
selecting,  imaging,  and  interpreting  ground-based 
features  and  associating  them  with  reference  source 
data  to  derive  navigation  updates.  Development  of  a 
real-time  AFM  system  ensured  mission  success  by 
maintaining  an  accurate  navigation  solution  without 
increased  crew  workload. 

The  AFM  system  used  a  Hyper- Velocity  Vehicle 
(HVV)  for  it's  baseline  study.  A  HVV  is  generally 
considered  to  be  a  vehicle  which  can  exceed  five 
limes  the  speed  of  sound,  or  mach  S.  The  vehicle 
under  consideration  in  the  AFM  program  is  assumed 
to  be  capable  of  rapid,  short-notice,  conventional 
takeoff,  climb  to  endoatmospheric  cruise,  and  if 
required,  insertion  into  low  earth  orbit.  The  goal  of 
the  AFM  system  was  to  integrate  tactical  sensors, 
processing,  mission  data,  and  map  databases  which 
existed  in  the  design  of  a  potential  HVV.  The 
mission  of  the  HVV,  for  the  purposes  of  this  program, 
was  high  accuracy  and  rapid  response  reconnaissance 
at  long  distances  from  the  launch  location. 

The  exceptionally  high  speed,  and  correspondingly 
short  mission  time,  associated  with  an  HW  have  the 
effect  of  increasing  crew  workload.  In  the  event  of 
GPS  failure,  the  mission  oriented  workload  is 
increased  due  to  a  decrease  in  time  available  for 
setup,  fixpoint  acquisition,  and  navigation  correction. 
As  supported  by  the  findings  of  aircraft  cockpit 
automation  studies  such  as  the  Air  Force's  Pilot's 
Associate  l^ogram,  the  greatest  mission  effectiveness 
payoffs  are  obtained  by  providing  the  crew  with 
information  that  enJiances  situational  awareness 
while  automating  system  management  tasks  required 
to  produce  the  information.  Reliable,  accurate 
ruvigation  is  key  to  crew  situation  awareness  and 
HVV  mission  success.  Automating  related 
management  and  operational  tasks  such  as  data 
consistency  monitoring,  mode  planning/switching  and 
sensor  image  interpretation  is  a  significant 
opportunity  to  improve  mission  effectiveness. 
Although  the  HVV  was  used  as  the  baseline  vehicle  it 
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Ui  easy  u>  9«c  how  the  lechnulogies  involved  and 
system  design  can  be  used  for  a  variety  of  missions 
and  airframes.  The  concepts  are  just  as  applicable  to 
a  tactical  mission  on  any  aircraft. 

This  paper  will  focus  on  the  software  engineering 
techniques  utilized  to  implement  the  AFM  system. 
The  AFM  system  used  modular  software  design  and 
object  oriented  devek^nnent  techniques  to  mtegrale 
models  of  existing  on-board  sensors,  processing, 
mission  data,  and  map  databases.  System 
requirements  were  developed  by  applying  an  in-depth 
knowledge  of  mission  requirements  and  real-time 
intelligent  avionics.  Several  diverse  technology 
disciplines  were  integrated  iiKluding  neural 
networks,  associative  memories  and  real-time  data 
fusion  architectures  to  develop  an  effective  and 
technologically  advaiKed  system.  Neural  networks 
along  with  other  automatic  target  recognition 
techniques  were  used  to  find  the  Tixpoints  from  the 
SAR  and  EO  images.  Associative  memories  provided 
real-time  retrieval  of  the  Tixpoints  from  on-board 
databases.  Finally,  the  activation  framework 
architecture,  a  real-time  object-oriented  data  fusion 
architecture,  was  used  to  integrate  the  overall  system 
and  provide  a  software  engineering  methodology  for 
sensor  management. 


3.  OVERALL  SYSTEM  DESIGN 

The  overall  system  design  integrated  several 
advanced  technologies  into  a  real-time  simulation  of 
the  AFM  system  as  illustrated  in  Figure  3-1 .  The 
system  design  was  developed  from  the  following 
conceptual  model.  First,  a  mission  plan  would  be 
given  to  the  pilot  and  possibly  loaded  onto  the 
aircraft.  The  mission  plan  provides  information  such 
as  route  plarming,  environmental  data,  and  target 
infmmalion.  The  real-time  simulation  required 
flexible  symbolic  logic  to  intelligently  utilize  the 
mission  plarming  and  in-flight  mission  data. 
Embedded  within  the  mission  plan  is  navigation  data, 
which  the  simulation  extracts  to  develop  a  navigation 
plan.  This  navigation  plan  consists  of  navigation 
modes  and  determines  the  aircraft  position  and  times 
to  send  navigation  updates  to  the  mission  matugcr. 

In  this  simulation  a-priori  plarming  information  was 
used  and  in-flight  replanning  was  done  in  the  real¬ 
time  navigation  plarming/monitoring  module.  As  the 
mission  path  is  traversed  Tixpoints  are  located  with 
simulated  sensors  and  compared  to  flxpoints  retrieved 
from  on-board  terrain  and  feature  daubascs.  This 
comparison  provides  a  navigation  offset  which  is  fed 
back  to  the  navigation  simulation.  The  large  fixpoini 
database  search  required  efficient  storage  methods 
and  the  image  interpretation  required  parallel 
processing  technology  to  achieve  real-time 
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Figure  3-2 .  AFM  High  Level  System  Design 


performance.  The  AFM  system  design  applied 
associative  memories,  artificial  neural  networks,  and 
AI  planning  technology  to  meet  the  real-time  system 
requirements. 

The  design  approach  used  for  the  AFM  system 
sepaiaied  the  simulation  into  four  major  sections;  the 
Mission  Manager,  Fixpoint  Locator,  Fixpoint 
Catalog,  and  the  Navigation  System  Filter  as 
illustrated  in  Figure  3-2.  The  majority  of  the 
Navigation  System  Filter  was  developed  under  the 
ATN  program  and  will  not  be  discussed  in  detail  for 
this  paper.  The  AFM  system  also  relied  on  an 
intelligent  data-Fusion  algorithm  partitioning  and 
system  development  approach  developed  under  ATN. 
The  approach  to  mission  management  is  based  on 
real-time  coordination  of  a  variety  of  cooperating 
agent  processes  orchestrated  by  an  intelligent  data 
fusion  agent;  the  Mission  Manager.  Two  critical 
agents  which  are  unique  to  AFM  are  the  Fixpoint 
Catalog  and  Fixpoint  Locator.  The  Fixpoint  Catalog 
employs  a  parallel  processing  associative  memory 
technology  to  solve  the  problem  of  selecting  a 
candidate  fixpoint  set  from  large  databases  of 
possible  relevant  terrain  features,  in  real-time.  The 
Fixpoint  Locator  utilizes  intelligent  feature 
classification  technology  to  automate  the  fixpoint 
recognition  activity  of  a  human  navigator. 

The  overall  system  design  focused  on  developing, 
maintaining,  and  utilizing  a  dynamic  mission  plan  to 
determine  navigation  moding  along  the  planned  flight 
path.  The  AFM  design  is  based  on  a  hierarchical 
decomposition  of  the  mission  planning  and  data 
interpretation  functions.  The  three  major  agents  in 


the  AFM  system  required  diverse  computational 
approaches  to  meet  the  real-time  performance 
requirements  of  the  HVV  environment.  An  object- 
oriented  design  and  integration  approach  was  used  to 
facilitate  agent  paradigm  encapsulation,  provide 
consistent  inter-agent  communication,  and  enable 
real-time  control  prioritization. 

At  the  lower  level  of  the  hierarchical  design, 
individual  software  modules  at  the  agent  level  were 
designed  to  communicate  using  the  same  message 
passing  paradigm.  The  module  design  benefited  from 
the  algorithm  encapsulation  which  allowed 
independent  development  of  agent  modules.  The 
consistent  inter  module  communication  interfaces 
allowed  concurrent  module  and  agent  development  by 
independent  designers. 

4.  MISSION  MANAGER 

The  overall  controller  of  the  system  is  the  Mission 
Manager.  The  Mission  Manager  agent  determines 
when  to  retrieve  upcoming  fixpoints  from  an  on-board 
data  base,  commands  SAR  and/or  EO  sensors  to 
image  fixpoi-iis,  and  orchestrates  correlation  of  these 
fixpoints  to  .  pdate  the  navigation  solution.  The 
Mission  Manager  is  the  executive  over  the  objects 
and  assures  cooperative  communication  and 
interaction.  The  underlying  architecture  allowing  the 
communication  structure  is  the  Activation  Framework 
(AF)  paradigm. 
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4.1  MISSION  MANAGER  DESIGN 

The  Mission  Manager  design  plans  navigation 
resource  utilization  on  a  mission  subleg  basis, 
schedules  fupoint  updates  to  the  navigation  filter, 
and  monitors  mission  navigation  performaitce  along 
the  planned  mission  route.  These  functions  are 
performed  by  the  Mission  Manager  utilizing  five 
major  components;  the  Mission  Tracker,  the  Leg 
Manager,  the  Envirorunental  Model,  the  Mission 
Script,  and  the  Effectiveness  Evaluation  as  shown  in 
Figure  4-1. 

The  Mission  Tracker  monitors  input  reports  of  the 
mission  progress  including  the  mission  position  and 
external  environment  The  Leg  Manager  uses  inputs 
from  other  Mission  Manager  modules  to  plan, 
implement  confirm,  and  maintain  navigation  system 
modes  and  functionality.  The  Environment  Model 
contains  a-priori  models  of  the  HW,  the  sensor 
conditions,  and  atmospheric  interactions  for 
intelligent  sensor  selection.  The  Mission  Script 
contains  information  on  the  mission  route,  targeting, 
and  emission  control  over  the  route.  The 
Effectiveness  Evaluation  module  monitors  futaking 
activity  to  ensure  that  fixes  are  valid.  Within  the 
Effectiveness  Evaluation  module,  the  Effectiveness 
Predictor  relies  on  the  built-in  checking  in  the 
Fixpoint  Catalog  and  Fixpoitu  Locator  to  assure 
accurate  operation  at  the  data  interpretation  levels. 
The  Mission  Scri]H  and  Environment  Model  contain 
pre-mission  planning  data  to  support  the  AFM 
systems  in-flight  platming  and  analysis. 

A  symbolic  mission  script  database  is  utilized  by  the 
Mission  Manager  Ur  maintain  mission  goals, 
requirements,  and  restrictions  as  well  as  to  schedule 


evetus  (e.g.,  fixpoint  updates).  The  Mission  Script  is 
a  result  of  pre-mission  planning  and  is  stored  in  the 
script  database.  This  script  database  consists  of  a 
series  of  leg  intervals  between  way  points,  which  is 
used  by  the  Requirements  Planner  to  setup  the  modes 
for  the  way  points.  The  Mode  Plainter  then  utilizes 
these  legs  to  determine  where  plaiuied  navigation 
mode  changes  are  needed.  The  integration  of  all  data 
and  activity  is  controlled  by  the  Fixtaking  Plaruier. 

The  mission  plan  is  stored  in  the  Script  Database  as  a 
tree  structure.  The  root  of  the  tree  represents  the 
entire  mission.  The  second  level  of  the  tree  shows  a 
series  of  mission  phases,  each  with  ptederined  in¬ 
flight  requirements.  The  third  level  of  the  tree 
consists  of  all  the  legs  in  the  order  in  which  they 
occur.  Some  legs  have  further  branches  which  end  in 
leaves  representing  subleg  intervals.  Traversal  of  the 
tree  along  the  bottom  leaves  corresponds  to  the 
schedule  of  luvigation  moding,  events,  and 
environment  along  the  mission  route. 

A  list  of  properties  characterizing  the  corresponding 
intervals  arc  represented  at  each  node  in  the  tree. 

The  properties  include  the  endpoints  of  the  interval, 
the  planned  nominal  mode,  fixpoint  locations,  GPS 
satellite  visibility,  and  a  list  of  requirements  for  the 
interval.  The  requirements  are  the  navigation 
accuracy  on  the  segment,  the  maximum  susceptibility 
to  Electronic  Counter  Measures  (ECM)  that  can  be 
tolerated,  and  electronic  radiation  restrictions.  These 
requirements  may  be  refined  by  the  Mission 
Manager. 

Along  each  leg  of  the  mission  route,  the  Mode 
Planner  and  Mode  Complex  objects  perform 
constraint-based  planning  for  the  optimal  navigation 
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mode  «d  prcfctied  f’.'vpoint  locations.  Planning  is 
based  on  a-priori  mission  requirements,  current 
navigation  mode,  and  physical  conditions. 

Consliaiitts  on  choice  of  sensors  and  fix  timing 
originate  at  initial  mission  download  and  at 
asynchronous  event  times.  Mission  replwning 
becomes  necessary  when  the  cunent  navigation  mode 
is  determined  unhealthy,  a  sensor  fails,  or  the 
expected  ECM  enviruiunent  changes. 


The  low  level  structures  such  as  the  clock  object, 
messages,  plaiming  structures,  mission  scripts,  and 
AF  communication  facilities  are  object-based  code. 
Object-based  structures,  such  as  messages, 
encapsulated  data  and  code,  provide  flexible 
input/output  entities,  which  localize  translation 
mechanisms  and  reduce  coding  errors.  The 
main  structure  is  provided  by  the  AF  and  the 
modules  under  this  architecture  called 
Activation  FramewOTk  Objects  (AFOs),  these 
concepts  are  further  explained  in  the  section 
below.  The  AF,  AFOs,  scripts,  all  message 
types,  message  bodies,  and  other  agent 
specific  objects  are  based  on  a  root  object 
class  which  specifies  default  access  utilities 
and  operators.  The  default  object 
capabilities  include:  print,  get,  put,  stream 
operators,  logical  operators,  and  other 
fundamental  functions,  and  data.  Where 
required,  specific  derived  objects  redefme 
default  access  functions  and  operators. 


sends  a  hst  of  times  to  the  Alarm  Clock.  When  a 
scheduled  wake  up  time  is  reached  the  Alarm  Cluck 
object  activates  the  Event  Tracker  which  sends  a 
message  to  the  Fixtaking  Planner.  If  the  Event 
Tracker  detects  that  the  plan  is  nearing  the  time  to 
take  a  navigation  update,  the  Event  Tracker  notifies 
the  Fixtaking  Planner. 

The  Fixtaking  Planner  estimates  the  position  of  the 
HVV  at  the  time  of  the  planned  fix  and  uses  specific 
calculations  to  determine  a  pomt  on  the  ground  which 
will  be  visible  to  that  sensor.  The  visible  point  is 
sent  to  the  Fixpoint  CaUdug  as  a  Candidate  Fixpoint. 
The  Fixpoint  Catalog  locales  a  known  fixpoint  for  the 
sensm  type  located  near  the  candidate  point  and 
returns  thu  fixpoint  to  the  Fixuking  Planner. 


Message  object  pointers  are  the  root  object 

type  and  can  be  decoded  using  the  built  in 

data  available  through  an  inherited 

parameter.  The  general  pointer  type  for 

many  objects  combined  with  the  type 

identifier  provide  the  capability  to  store  the  dissimilar 

objects  in  the  same  dau  structures.  The 

homogeneous  storage  mechanism  allows  for  compact 

list  and  object  storage.  The  simulation  and  planning 

code  is  simplified  as  a  result  of  the  compact,  unified 

storage  representation. 

The  Fixtaking  Planner  design  interface  is  illustrated 
in  Figure  4-2.  The  Fixtaking  Planner  links  the 
Mission  Manager  to  the  AFM  subsystems,  the  AFM 
Fixpoint  Catalog,  and  Fixpoint  Locator.  The 
Fixtaking  Plarmer  is  a  control  focus  in  the  AFM 
architecture,  orchestrated  in  an  AFO  under  the 
Mission  Manager.  All  communication  is  conducted 
through  the  AF  facilities.  The  Fixtaking  Planner 
AFO  uses  messages  to  communicate  with  the 
Effectiveness  Prediction,  hfode  Complex,  and  Event 
Tracker  Mission  Manager  AFOs. 

The  Fixiaking  Plarmer  uses  the  interfaces  illustrated 
in  Figure  4-2  to  orchestrate  fixpoint  iqxlates  and 
navigation  mode  changes.  When  a  plan  is  created  or 
a  replanning  event  is  completed  the  Fixtaking  Plarmer 
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When  the  HVV  is  near  the  area  of  the  fixpoint,  the 
Fixiaking  Plarmer  sends  the  candidate  fixpoint  \o  the 
Fixpoint  Locator  which  images  the  area,  locates  the 
fixpoint  in  the  image,  and  returns  a  navigation  offset. 
The  Fixtaking  Plarmer  checks  validity  of  the 
navigation  update  before  sending  the  update  to  the 
navigation  fUter. 

4.2  ACTIVATION  FRAMEWORK 
ARCHTIBCTURE 

The  Activation  Framework  (AF)  concept  is  based  on 
an  approach  to  real-time  object-oriented 
implementation  known  as  Communicating  Expert 
Objects  (CEO).  In  the  CEO  approach  hypotheses  are 
distributed  among  expert  objects  that  communicate 
with  each  other  by  exchanging  messages  as  shown  in 
Figure  4-3.  Procedures  within  an  ATN  or  AFM 
expert  object  contain  both  factual  hypothesis 
knowledge  and  procedural  knowledge  relating  to  its 
functional  domain  (e.g.,  mission  management). 
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An  AF  fonns  a  community  of  AFOs  (Activation 
Frame  Objects)  as  shown  in  Figure  4-4.  Each  AFO  is 
an  eapeit  in  a  limited  problem  domain  and  is  the 
guardian  of  a  set  of  private  hypotheses.  Each  AF  is  a 
process  which  creates  the  environment  in  which  all  of 
its  AFOs  execute.  Multiple  AFs  might  coexist  on  the 
same  pnxxssor  or  on  multiple  processors  connected 
by  a  network,  as  shown  in  Figure  4-S. 
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An  AF  is  equivalent  to  a  process  executing  within  an 
operating  system.  Communication  between  AFOs  is 
provided  by  AF  services  using  a  message  passing 
mechanism.  Message  passing  among  AFOs  is 
implemented  by  operating  system  level  message 
passing  mechanisms  including,  in  the  case  of  multiple 
processors,  network  protocol  processing. 

The  flow  of  control  within  an  AF  is  shown  in  Figure 
4-6.  The  scheduler  selects  the  next  AFO  to  be 
activated.  The  procedural  code  of  the  activated  AFO 


is  then  executed.  The  AFO  can  then  use  differem  AF 
services  (tyiacally  ittessage  sending  and  message 
receiving)  during  the  execution  of  the  procedural 
code.  When  the  AFO  returns  control,  the  messages 
sent  during  its  execution  are  actually  delivered  to  the 
receiving  AFOs. 
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Each  AFO  has  an  input  message  queue  and  an  output 
message  queue.  Message  sending  and  receiving  is 
depicted  in  Figure  4-7.  When  an  AFO  wants  u>  send 
a  message,  the  message  is  put  on  its  output  message 
queue  by  an  AF  sovice.  When  an  AFO  wants  to 
receive  a  message,  the  message  is  taken  off  the  AFO  s 
input  message  queue  and  made  available  by  an  AF 
service.  The  actual  passing  of  the  message  from 
origituuing  AFO  to  destination  AFO  (either  within  or 
outside  the  AF)  is  done  by  the  delivery  procedure 
after  the  AFO  returns  control  to  its  governing  AF. 


In  the  current  scheduling  scheme,  each  message  is 
provided  with  a  measure  of  its  importance,  the 
message  activation  level.  Each  AFO  has  an  AFO 
activation  level  and  an  AFO  activation  threshold  is 
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used  by  die  scheduler  lo  detenniiie  which  AFO  is 
nest  to  execute.  The  AFO's  acdvatian  level  is  (he 
sum  of  all  the  message  activation  levels  on  its  input 
message  queue.  An  AF  schedules  its  AFOs  for 
execudon  based  on  the  difference  between  their 
acdvadan  levels  and  activation  thresholds.  The  AFO 
whose  activation  level  exceeds  its  threshold  by  the 
greatest  amount  is  executed  next.  All  messages  on 
that  AFO's  queue  are  then  serviced. 

The  advantage  of  the  AF  architecnire  is  that  unlike 
ghibal  blackboard  structures  die  scheduling 
mechanism  is  distributed  throughout  the  system. 

This  distributed  scheduler  removes  the  bottleneck  of 
all  processes  going  to  one  centralized  scheduler,  thus 
allowing  the  achievement  of  real-tiine  performance. 
Another  advantage  the  encapsulation  mechanism 
provides  is  that  symbolic  as  well  as  numerical 
processes  can  be  run  under  a  common  framework. 


5.  FDCPOINTCATAIjOG 

The  high  speed  of  the  H  W  limits  the  temporal 
window  of  opportunity  on  fixpoints.  At  100,000  ft 
altitude  mach  6  flight,  (he  time  from  when  a  flxpoint 
appears  on  the  forward  horizon  until  it  disappears 
into  the  aft  horizon  is  approximately  40  seconds. 

This  time  limitation  requires  preselection  of 
candidate  lixpoints  prior  to  arriving  at  (hat  location  in 
the  mission.  The  Fixpoint  Catalog  uses  a  preferred 
kxdc  location  from  the  Mission  Manager  to  retrieve  a 
fixpoint  of  the  appropriate  type,  (e.g.,  SAR,  EO)  in  a 
fixed  time  poiod.  The  output  from  the  Fixpoint 
Catalog  is  used  by  the  Fixpoint  Locator  to  obtain  a 
sensor  image  of  the  appropriate  ground  region  and  to 
locate  the  predetermined  features  within  that  image. 

5.1  OVERALL  FIXPOINT  CATALOG  AFO  DESIGN 

The  Fixpoint  Catalog  associative  memory  algorithm 
described  below  is  encapsulated  in  an  AFO.  The 
AFO  will  handle  communicatian  between  the 
Fixpoint  Catalog,  the  Mission  Manager,  and  the 
Fixpoint  Locator.  In  the  initial  prototype  this  AFO 
loaded  geogiiqihically  relevant  groups  of  fixpoiius 
into  the  storage  matrix.  The  storage  matrix  loads  are 


file  I/O  perfonned  sequentially  as  the  mission 
progresses. 

5.2  ASSOCIATIVE  MEMORY  TECHNOLOGY 

To  facilitate  rapid,  constant-time  candidate  fixpoint 
retrievaL  an  associative  memory  approach  is 
employed  in  (he  fixpoint  catalog.  The  fundamental 
approach  is  illustrated  in  Figure  5-1 .  The  fixpoint 
attributes  are  encoded  as  a  vector,  and  run  through  an 
iterative,  simulated,  parallel  search  of  the  fixpoints 
stared  in  the  associative  memory. 
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The  associative  memory  is  a  dau  retrieval  approach 
which  conducts  a  parallel  search  of  a  large  database 
returning  a  data  record  which  is  "closest"  to  an  input 
record.  The  following  example,  see  Figure  5-2, 
illustrates  the  application  of  this  technique  to  the 
AFM  fixpoint  using  two-dimensional  fixpoint  space 
with  four  fixpoints.  The  example  encoding  uses  (he 
difference  in  latitude,  longitude,  altitude,  and  a 
reference  number  to  identify  and  differentiate 
fixpoints.  The  normalized  matrix  of  fixpoints,  S,  is  a 
n  X  4  matrix  where  the  rows  represent  the  possible 
centroid  of  a  multiple  feature  fixpoint  region. 
Fixpoints  include  a  fixpoint  identifier,  and  a  sensor 
type  embedded  in  the  type  identifier. 

Figure  5-3  illustrates  the  matrix  based  associative 
memory  algorithm,  and  data  forms  used  in  the 
Fixpoint  Catalog.  The  vectors,  V,  will  contain  the 
encoded  fixpoints  as  previously  illustrated.  Vectors 
pertinent  to  the  mission  leg  will  be  stored  in  the 
matrix,  S,  and  their  dot  products  will  be  used  to 
derive  the  nonlinear  function  matrix,  F.  The  diagonal 
values  of  the  nonlinear  function  matrix  are  the 
maximum  of  the  dot  products  of  that  row's  fixpoint 
with  the  other  tow's  fixpoinis  plus  a  hcuristically- 
derived  offset  The  heuristically  derived  offset  is  a 
small  constant  added  to  the  largest  dot  product  to 
help  distinguish  a  near  miss  with  one  row  fiom  a  near 
miss  with  another  row;  this  system  uses  a  value  of 
0.05  (or  five  percent).  Using  the  previously  illustrated 
normalized  storage  matrix,  S,  fiom  Figure  5-2,  the 


m 


20  fttpMMnIrtvi  Fhqwint  Sub-Map 


Eneottod  FbcpeMi 


Bat 

1 

AUwa, 

7J 

AUL 

17A 

2 

425 

«2A 

5 

77J 

KS 

4 

KJ 

7.8 

0.02 

0.13 

0A1 

0J4 

0.03 

0.S6 

0.31 

0.19 

0.02 

0.64 

0.63 

03S 

0.04 

0.04 

0.07 

064 

S  >  MaMi  of  Nonrwkid  Ripeint-Roin 


25  SO  78 

A  Longfejda  Oag^lOO 


Figure  5-2.  Fuqpoint  Vector  Encoding  Euinple 


unsealed  non-Unear  function  matrix  is  given  by 
Equation  5-1,  with  the  heuristic  oifset  equal  to  zero. 


Equation  5-1 


The  final  equation  in  Figure  5-3  is  the  retrieval 
approach.  The  input  vector  Vi  is  multiplied  into  the 
storage  matrix  resulting  in  a  one  dimensional  vector 
of  dot  products  between  the  approximate  vector  and 
the  set  of  stored  fixpoint  vectors.  The  vector  of  dot 
products  is  multiplied  by  the  non-linear  function 
matrix  resulting  in  a  vector  of  scaled  dot 
products.  This  vector  is  multiplied  back  into  the 
storage  matrix  to  extract  the  recall  vector.  For 
example,  the  0.64  in  the  first  row  and  column  is 
derived  horn  the  fact  that  the  first  row  of  N  has 
the  highest  dot  product  with  row  three;  that  dot 
product  is ; 

0.64  =  (0.02*0.02)+(0.13*0.64)-^(0.3 1*0.68)+ 
(0.94*0.35). 

Any  input  vector  having  a  dot  product  with  a 
given  row  of  S  below  the  associated  threshold 
value  in  the  F  matrix  is  more  closely  aligned 


with  one  of  the  other  vectors  in  the  storage  matrix. 
Thus,  if  the  dot  product  of  the  input  fixpoint  and  a 
given  tow  is  below  threshold  value  for  the  tow, 
candidate  fixpoint  information  associated  with  that 
row  is  suf^iressed. 

The  final  equation  in  Figure  5-3  shows  the  method  of 
retrieving  a  fixpoint  vector  from  the  storage  matrix. 
This  equation  constitutes  the  parallel  search  in  Figure 
5-1.  This  approach  can  be  applied  iteratively,  if 
necessary,  to  retrieve  a  single  candidate  fixpoint 

The  associative  memory  described  here  was 
prototyped  and  tested  with  representative  data;  tests 
often  yielded  perfect  recall.  The  algorithm,  however, 
sometimes  iterates  to  a  deadlock  solution,  especially 
between  fixpoints  which  have  a  small  four-space 
separation.  In  these  cases,  either  solution  is  equally 
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Figure  5-4.  AFM  Fixpoint  Catalog  Example 


acceplable.  A  random  choice  between  "tied" 
solutions  appears  to  be  a  viable  and  reasonable 
design  approach.  This  approach  is  illustrated  in 
Figure  5-4. 


6.  FIXPOINT  LOCATOR 

The  AFM  FUpoint  Locator  acquires  and  interprets 
sensor  images  to  obtain  navigation  offsets  which  are 
input  to  the  navigation  filter.  The  Fbtpoint  Locator 
receives  a  fixpoint  and  an  associated  mission  time  to 
image  it  fro^  the  Mission  Manager.  The  Fixpoint 
Locator  sets  up  the  sensor  and  compares  a  processed 
image  to  on-board  databases,  resulting  in  a  navigation 
offset. 

A  block  diagram  of  the  AFM  Fixpoint  Locator  is 
illustrated  in  Figure  6-1 .  The  image  interpretation  is 
a  multistep  process  involving  traditional  image 
preprocessing,  neural  network  classification,  and 
heuristic  fixpoint  location  logic  based  on  ATN 
interviews  with  strategic  aircraft  navigators.  This 
logic  returns  a  two-dimensional  navigation  offset 
which  is  passed  to  the  Mission  Manager  through  the 
AF  communication  interface.  These  system 
components  are  detailed  in  the  following  sections. 


6.1  FIXPOINT  LOCATOR  AFO  INTERFACE 

The  Fixpoint  Locator  Logic  algorithm  described 
above  was  encapsulated  in  an  AFO  which  handles 
communication  details  among  the  Fixpoint  Locator. 
Mission  Manager,  and  Fixpoint  Catalog.  The  AFO 
internal  design  abo  incorporates  the  translation 
capabilities  for  the  navigation  offset  produced  by  the 
Fixpoint  Locator.  It  is  formatted  into  a  navigation 
update  message  suitable  for  dispatch  to  the 
Environment/Navigation  Simulation.  The  navigation 
update  message  contains  the  sensor  dependent  update 
type  and  the  two  dimensional  navigation  offset  (in 
meters). 


6.2  NEURAL  NETWORK  TECHNOLOGY  FOR 
IMAGE  PREPROCESSING 

The  Fixpoint  Locator  receives  a  fixpoint  and  a 
mission  time  to  image  the  fixpoint  from  the  Mission 
Manager.  The  Fixpoint  Locator  in  an  operational 
HVV  would  set  up  the  sensor  and  capture  the  live 
image.  In  the  simulation,  a  preprocessed  image  of  the 
area  of  the  fixpoint  is  retrieved  from  memory.  The 
image  interpretation  is  a  multistep  process  involving 
traditional  image  preprocessing  and  neural  network 
classification.  The  AFM  development  is  not 
specifically  concerned  with  the  detailed  sensor  image 
acquisition  and  signal  processing,  only  the  result  of 


Figur«  6-1 «  AFM  Pixpoint  Locator  Overall  Design 


these  prcKesses  on  the  etrors  inclined  in  the 
calculated  navigation  offset  As  illustrated  in  Figure 
6-1.  the  raw  sensor  image  is  first  processed  by  the 
image  processing  techniques  of  window  texture 
calculation  (standard  deviation)  and  edge  preserved 
smoothing  (EPS). 

The  standard  deviation  processing  helps  to  remove 
false  returns  and  dropouts  while  the  EPS  groups  the 
feature  pixels  into  closed  regions.  These  processing 
techniques  produce  a  binary  output.  The  neural 
network  takes  this  binary  output  and  identifies 
features  in  the  image.  The  neural  network 
accomplishes  this  by  performing  a  pixel-by-pixel 
determination  of  which  image  pixels  arc  features  of 
the  image,  and  which  are  not 

The  artificial  neural  network  simulation  model  used 
is  a  three  layer,  fully  interconnected  back  propagation 
system.  It  has  two  input  nodes,  eight  hidden  layer 
nodes,  and  two  output  nodes.  The  output  of  the 
neural  network  classifier  is  a  dual  floating  point  value 
which  refuesents  a  binary  number.  For  the  purposes 
of  the  AFM  simulation,  the  image  pixel  classification 
is  done  off-line.  The  SAR  images  used  were 
unclassified  SeaSat  SAR  images.  If  the  resolution  is 
assumed  to  be  about  S  to  10  times  better  than  actual, 
the  images  are  representative  of  the  HW  SAR 
returns.  The  dual-valued  neural  network  outputs  are 


reformatted  into  binary- valued-images  which  are  used 
by  the  on-line  portion  of  the  FixpoinI  Locator  system. 

The  on-line  portion  of  the  Fixpoint  Locator 
simulation  reads  the  preprocessed  sensor  image  and 
offsets  it  to  represent  the  navigauion  and  sensor 
pointing  errors.  The  errors  modeled  are  both 
systematic  and  random.  The  Fixpoint  Locator 
simulation,  therefore,  requires  that  the  true  position 
of  the  HW,  which  is  maintained  in  the  environment 
simulation,  be  passed  to  it  The  preprocessed  image 
is  offset  to  represent  the  image  coordinates  which 
would  have  resulted  from  sensor  imaging  in  an 
operational  system.  The  fixpoint  locator  logic  is  then 
employed  to  locate  the  fixpoint  features. 

6.3  FIXPOINT  LOCATOR  HEURISTIC  LOGIC 
DESIGN 

The  fixpoint  location  logic  was  developed  based  on 
intorviews  with  FB-1 1 1  navigators  conducted  during 
the  ATTf  system  development.  When  searching  a 
sensor  image  for  a  known  fixpoint,  the  navigators 
first  searched  for  large  recognizable  features,  then 
smaller  collateral  features,  until  the  location  of  the 
relatively  small  fixpoint  could  be  reliably  determined. 
This  methodology  has  been  adapted  to  AFM  and 
tested  using  the  fneprocessed  LandSat  images.  As 
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UlusHaled  in  Figure  6-2.  fixpoints  ire  composed  of  a 
Tine  flxpoint,  and  two  collateral  features. 

One  of  the  collateral  features  has  a  radius 
approximately  as  large  as  the  expected  navigation 
error  plus  the  sensor  pointing  error.  This  large 
feature  must  be  in  a  region  which  is  devoid  of  other 
features  of  the  same  approximate  size  and  area.  The 
Fixpoint  Locator  logic  feature  search  begins  at  the 
point  where  it  would  be  expected  in  the  image.  The 
search  area  is  initially  a  heuristically-determined 
multiple  of  the  feature  radius.  Note  that  by 
definition,  this  is  a  function  of  the  expected 
maximum  total  offset.  If  the  logic  fails  to  locate  the 
feature,  this  search  space  is  expanded.  Once  the 
coarse  feature  is  located,  its  centroid  is  calculated, 
and  the  offset  between  its  expected  position  and  the 
calculated  position  is  used  to  locate  the  third,  and 
final,  fixpoint  feature.  The  resulting  offset  is  the 
navigation  delta  after  bemg  scaled  out  of  pixel  space 
into  equivalent  navigation  measurements. 
Quantization  error  proportional  to  the  sensor 
resolution  exists,  but  with  the  fine  resolution  of  the 
proposed  SAR  and  EO  sensors.  (1-S  meters),  the 
sensor  boresight  alignment  errors  dominate. 

Within  a  feature  search  area,  the  Fixpoint  Locator 
logic  conducts  a  simple,  connected  pixel,  region¬ 
building  search.  The  feature  is  found  and  confirmed 
by  the  constraint  that  a  fixpoint  feature  must  be  the 
largest  localized  feature  within  the  approximate  area 


expected.  False  identincatioiu  are  minimized  by  this 
constraint  as  well  as  the  relative  geometry  which 
must  be  esublished  and  confirmed  with  collateral 
features. 


7.  SYSTEM  DEVELOPMENT  AND 
INTEGRATION 

The  AFM  system  was  designed  and  developed  using 
an  object-oriented  programming  based  approach 
leveraging  the  real-time  process/module  integration 
benefits  of  Activation  Frameworks.  AF  was 
implemented  in  as  a  real-time  sub-set  of  object- 
oriented  programming  techniques.  The  AF  provides  a 
consistent  inter-agent  interface,  which  utilizes  object- 
based  message  passing  and  flexible  focus  of  control 
using  message  importance  and  priority.  The  three  top 
level  system  agents,  the  Mission  Manager.  Fixpoint 
Catalog,  and  Fixpoint  Locator,  were  designed  and 
developed  independently  once  a  set  of  messages  and 
an  associated  prioritization  scheme  was  established. 
Each  of  these  agents  were  designed,  from  top  level 
requirements  and  lessons  learned  in  previous 
programs,  by  separate  developers. 

Conventional  object-oriented  programming 
paradigms,  like  C-t-f.  process  a  single  thread  of 
control  through  object  messages  which  represent  a 
sequence  of  data  events.  In  a  conventional  C-i-i- 
implementation  the  control  of  data  event  processing 
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follows  processing  paths  of  undetermined  lengths. 

The  AF  is  built  on  the  C**  object  model  but  at  each 
object  message  initiation,  a  new  processing  thread  is 
created  or  an  old  thread  comes  nearer  to  activation. 
Thus,  each  time  an  object  relinquishes  control  of  the 
computer  process,  system  control  is  passed  to  an 
object  which  most  urgently  requires  the  processor  or 
which  produces  output  most  important  to  the 
propagation  of  other  process  threads.  The  AFM  AF 
uses  this  control  to  allocate  computer  resources  to  the 
agent  and  agent  sub-objects. 

The  design  of  each  agent  was  selected  to  optimize 
required  aspects  of  agent  performance.  The  Mission 
Manager  was  designed  as  a  set  of  C*+  objects  which 
were  encapsulated  in  the  AF  as  AFOs.  Because  of 
the  success  of  the  ATN  mission  planning  system,  the 
Mission  Manager  was  designed  as  a  large  number  of 
AFOs,  which  separated  the  A1  and  conventional 
programming  modules  into  a  set  of  objects.  These 
objects  were  tightly  integrated  using  a  fixed  set  of 
messages  to  enhance  real-time  control.  The  Fixpoint 
Catalog  was  designed  as  several  €++  objects  and 
some  procedural  code  which  was  encapsulated  as  a 
single  AFO  to  enhance  data  retrieval  speed  and 
control  data  passing  and  translation  activity.  The 
Fixpoint  Locator  was  designed  as  a  C++  object  with  a 
large  procedural  content.  The  Fixpoint  Locator  works 
wtih  large  images  performing  several  stages  of 
processing  on  the  input  image.  This  image 
piiKessing  approach  included  some  conventional 
processing  algorithms  which  were  procedural  in 
nature,  calling  for  the  localization  of  the  object. 

The  Mission  Manager  developed  under  the  ATN 
system  was  originally  developed  around  an  expert 
system  and  causal  network  in  the  LISP  language. 
Real-time  constraints  forced  the  entire  ATN  system  to 
be  written  in  C.  The  ATN  Mission  Manager  operated 
as  a  subset  of  the  system  AFOs.  with  a  gateway  AFO 
used  as  the  sole  input/output  port  to  other  top  level 
agents.  The  ATN  gateway  AFO  re-sends  received 
mput  messages  to  Mission  Manager  AFOs.  This 
gateway  AFO  and  the  loose  coupling  of  message  data 
Structures,  AFO  data  structures,  and  the  AFO 
scheduling  system  made  modification  and  upgrade  of 
the  system  difficult.  The  requirement  of  a  gateway 
AFO  and  the  difficulty  of  specifying,  on  a  system¬ 
wide  basis,  the  method  for  decoding  particular 
messages  spawned  the  requirement  to  move  toward 
an  object-oriented  AF  system  for  the  AFM  program. 
The  ATN  gateway  AFO  illustrates  that  a  single  level 
of  object  separation,  scheduling,  control,  and 
aggregation  is  also  not  sufficient  in  a  complex 
application  like  navigation  mission  management. 

The  AFM  Mission  Manager  uses  the  list  oriented 
mission  decomposition  and  (danning  system 
implemented  under  a  C++  based  AFO.  The  AFM 
causal  network  engine  also  takes  advantage  of 


object-oriented  encapsulation  under  a  list  processing 
system  shared  with  the  other  planning  AFOs 

The  AF  system  exploits  the  objcct-oricnicd  benefits 
of  C++ in  several  cntical  ways.  AFOs  are  used  to 
encapsulate  both  procedural  code  and  objects  which 
are  called  or  accessed  by  an  mcoming  message  The 
AFOs  are  complex  enough  to  know  if  sufficient  data 
has  arrived  for  sub-object  or  procedure  activation 
The  messages  in  the  system  are  also  objects,  each 
having  a  consistent  extraction  mechanism  as  well  as  a 
consistent  scheduling  inlerface.  The  messages  use 
object  methods  and  overloaded  operators  to  facilitate 
these  features 

The  list  processing  system  is  a  C-based  system  which 
pre-dates  the  ATN  program  The  object-oriented 
features  of  C+ +  including  inhentance  has  been  used 
to  encapsulate  this  system  and  make  it  available  to 
multiple  other  system  objects.  The  planner  object 
uses  the  list  processing  system  extensively  The 
encapsulation  of  existing  routines  was  used  several 
places  in  the  AFM  system. 

The  messages  illustrated  in  Figure  7-1  comprise  the 
integration  design  of  the  complex  agent  models  used 
in  the  AFM  system.  Top  level  agent  decomposition 
was  determined  according  to  avionics  equipment, 
function,  and  existing  models  (i.e..  the  miss.on 
manager  and  navigation  simulation).  The  small 
number  of  messages  indicate  that  the  system 
decomposition  was  successful  at  maximizing  agent 
encapsulation  while  minimizing  the  passing  of  data. 
The  most  difficult  integration  challenge  was  the 
integration  of  the  PC-based  Navigation  Simulation,  a 
stand-alone  simulation  which  was  developed  over 
several  programs,  into  the  AFM  simulation.  The 
illustrated  messages  between  the  Navigation 
Simulation  and  the  Mission  Manager  agent  occurred 
over  a  RS-232  serial  line.  The  serial  link 
necessitated  the  use  of  the  handshaking  signals. 
Fix_Update_.Status  and  Reconfiguration_Complete. 
Except  for  the  necessary  handshaking  messages,  the 
design  represents  an  exceptionally  clean  design. 

8.  CONCLUSIONS 

AFM  was  a  challenging  application  which  required 
seamless  real-time  integration  of  several  advanced 
technologies  to  demonstrate  the  feasibility  of  an 
autonomous  navigation  fixtaking  capability.  The 
AFM  system  simulation  components  were  developed 
through  prototyping  and  verified  with  representative 
databases  to  ensure  real-time  performance.  In  order  to 
organize  the  AFM  program  into  a  manageable  system, 
a  hierarchical  decomposition  of  the  mission  planning 
and  data  interpretation  functions  were  utilized. 

Within  the  hierarchical  organization,  an  object- 
oriented  design  and  integration  approach  facilitated 
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agent  paradigm  encapsulation,  provided  consistent 
inter -agent  communication,  and  enabled  real-time 
control  prioritization.  The  AFM  software  modularity 
and  flexibility  were  further  enhanced  by  taking 
advantage  of  the  object-oriented  capabilities  of  C-t-+ 
m  implementing  the  Af.  With  the  use  of  the  AF 
architecture,  individual  software  modules  at  the  agent 
level  were  designed  to  communicate  using  the  same 
message  passing  paradigm. 

in  order  to  manage  the  system,  locate  fixpoints.  and 
retrieve  fixpoints  from  databases  three  major  object 
agents  were  developed.  These  agents  required 
diverse  computational  approaches  to  meet  the  real¬ 
time  performance  requirements  of  the  HVV 
environment.  The  AFM  Mission  Manager  was 
developed  based  on  extensive  lessons  learned  from 
the  ATN  design.  This  Mission  Manager  utilized  the 
AF  to  embed  intelligent  methodologies  on  mission 
planning,  analysis,  and  moding.  The  Fixpoint 
Catalog  demonstrated  the  real-time  capable  fixpoint 
retrieval  techniques  based  on  advanced  associative 
memory  technology.  The  Fixpoint  Lxx:ator  simulation 
achieves  efficient  image  feature  recognition  by 
emulating  human  feature  identification  processes 
captured  through  interviewing  tactical  aircraft 
nav'gators.  The  image  processing  techniques  achieve 
automated  fixpoint  location  and  i^omise  real-time 
operational  performance  through  the  application  of 
advanced  parallel  processing  algorithms.  The  module 
design  benefited  from  the  algorithm  encapsulation 
which  allowed  independent  development  of  agent 


modules.  A  well  defmed  real-tune  control  approach 
with  consistent  inter  module  communication 
interfaces  allowed  simultaneous  module  and  agent 
development  by  muluple  developers 

The  results  and  experiences  gained  from  this  program 
not  only  demonstrated  the  feasibility  of  automating 
the  navigation  fixtaking  task  but.  equally  important, 
demonstrated  the  integration  of  several  diverse 
technologies  working  in  concert.  Through  the  use  of 
software  techniques  such  as  hierarchical  organization, 
object-oriented  design,  and  the  AF  data  fusion 
methodology  real-time  performance  was  achieved. 
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Discussion 


Question  K.  ROSE 

What  navigation  accuracies  can  be  achieved  with  the  AFM  system? 

Reply 

This  system  was  designed  and  tested  through  simulation  for  approximately  60  meteis  accuracy. 
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1.  SUMMARY 

The  Italian  satellite  (with  a  l^tge  Dutch 
contribution)  SAX  Is  a  scientific  satellite  which 
has  the  Mission  to  study  rOntgen  sources.  One  aain 
requireaent  for  the  Attitude  and  Orbit  Control 
Subsystea  (AOCS)  la  to  achieve  and  aalntain  a 
stable  pointing  accuracy  with  a  Halt  cycle  of  less 
than  90  arcsec  during  pointings  of  aaxiaal  28 
hours.  The  aain  SAX  instruaent,  the  Narrow  Field 
Instruaent,  is  highly  sensitive  to  (Indirect) 
radiation  coming  froa  the  Sun.  This  sensitivity 
leads  to  another  aain  requireaent  that  under  no 
circumstances  the  safe  attitude  domain  aay  be  left. 

The  on-board  software  that  controls  the  SAX  AOCS 
aust  therefore  be  highly  reliable  with  respect  to 
the  safeguarding  of  the  satellite  attitude.  On  the 
other  hand,  the  scientific  character  of  the  mission 
imposes  flexibility  requirements  to  the  software, 
as  during  the  alssion  the  need  for  new  (or  changed) 
observation  types  aay  arise.  These  have  to  be 
implemented  by  loading  updated  software  during  the 
mission. 

The  AOCS  on-board  application  software  is  being 
developed  by  NLR  using  a  suite  of  CASE  tools 
consisting  of  the  Teamwork  package  (prescribed  for 
all  SAX  on-board  software),  the  CAOESE  software 
configuration  management  package.  processor 
emulation  hard-  and  software  and  a  number  of 
special  test  and  simulation  tools.  The  AOCS 
processor  and  its  operating  system  have  been 
developed  in  parallel  by  another  firm. 

The  paper  describes  the  application  software  in 
relation  with  the  overall  S/^  AOCS  subsystem,  the 
CASE  tools  chat  have  been  used  during  the 
development,  some  advantages  and  disadvantages  of 
Che  use  of  these  Cools,  Che  measures  taken  Co  meet 
Che  more  or  less  conflicting  requirements  of 
reliability  and  flexibility  and  the  lessons  learnt 
during  development. 

The  quality  of  the  approach  to  the  development  has 
been  proven  the  (separately  executed) 
hardware/software  integration  tests.  During  these 
tests  a  neglectible  number  of  software  errors  has 
been  detected  in  Che  application  software 

2.  INTRODUCTION 

In  the  early  1980' s  Che  Italian  Space  Agency  (ASX), 
together  with  the  Netherlands  Organisation  for 
Space  Research  (SRON),  started  the  development  of 
the  SAX  satellite  project  (Ref.  1).  Mission  of  the 
SAX  satellite  is  to  perform  a  systematic  and 
comprehensive  observation  of  celestial  X-ray 
sources  in  the  0.1-200  keV  energy  range  with 


particular  emphasis  on  spectral  and  timing 
measurements .  The  mission  is  funded  by  the  Italian 
and  Dutch  national  space  agencies,  resp.  ASI  and 
NIVR.  The  satellite  (Fig.  1)  will  be  injected  into 
a  circular  equatorial  orbit  with  an  inclination  of 
less  than  5*  and  an  initial  altitude  of  600  km  by 
an  Atlas  Centaur  launcher  in  the  last  quarter  of 
1994.  The  nominal  mission  lifetime  is  two  years, 
with  a  design  goal  of  four  years. 


Fig.  1  SAXsateifite 


The  Attitude  and  Orbit  Control  Subsystem  (AOCS)  of 
the  satellite  is  under  development  by  Fokker  Space 
and  Systems  (FSS)  under  contract  with  the  satellite 
prime  contractor  Alenia  Spazio  (Roma,  Italy).  As 
subcontractor  of  FSS,  the  National  Aerospace 
Laboratory  NLR  develops  the  Application  Software 
for  the  AOCS  on-board  computer  (Ref.  2). 

In  this  paper,  a  short  overview  of  the  application 
software  in  relation  with  the  overall  AOCS 
subsystem  is  given.  The  main  requirements  on  the 
software  are  discussed.  Besides  requirements  on  a 
high  pointing  accuracy,  it  is  Important  that  the 
software  is  highly  reliable  and  yet  flexible  for 
future  (in-orbit)  updates.  The  design  measures  to 
obey  to  these  more  or  less  conflicting  requiresMnts 
are  described. 

During  the  development  of  the  application  software, 
a  suite  of  Computer  Aided  Software  Engineering 
(CASE)  tools  is  applied.  Our  current  experience 
with  these  tools,  in  terns  of  recognised  advantages 
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and  disadvantagaa  Is  given.  This  experience  is 
related  with  previous  projects  that  were  similar  in 
size  and  complexity,  such  as  the  on-board  software 
for  the  satellites  ANS  and  IRAS  and  the  software 
for  groundstatlons . 

Host  of  the  software  has  been  Integrated  with  the 
AOCS  computer  and  tested  in  a  simulated 
environment.  During  these  tests  only  a  few  errors 
have  been  found,  illustrating  the  quality  of  the 
development  approach.  The  paper  ends  with  some 
lessons  learnt  during  the  development. 

3.  THE  SAX  AOCS  APPLICATION  SOFTWARE 

The  AOCS  subsystem  hardware  consists  of  vPig.  2): 
The  Attitude  ControL  Computer  (ACC).  This 
computer  is  based  on  a  80C86  microprocessor 
extended  with  a  8087  co-processor.  The  ACC  Is 
fully  redundant.  Two  identical,  independent, 
computers  are  integrated  Into  one  unit.  One  of 
the  two  is  cold  standby. 

A  set  of  attitude  sensors.  These  are: 

*  Three  Sun  Acquisition  Sensors  (SAS). 

*  Two  Quadrant  Sun  Sensors  (QSS). 

*  Two  Magnetometers  (HCH) . 

•*  Four  gyro's  (GYR) . 

*  Three  Star  Trackers  (STR). 

A  set  of  actuators.  These  are: 

*  Four  Reaction  Wheels  (RWL). 

*  Three  Magnetic  Torquer  Rods  (HTR) . 

*  A  Reaction  Control  Subsystem  (RCS)  containing 
thrusters  that  will  be  used  for  variation  of 
the  satellite's  velocity  in  orbit. 

A  set  of  service  units: 

*  A  Monitoring  and  Reconfiguration  Unit  (MRU). 

*  A  Power  Distribution  Unit  (POU). 

These  units  are  connected  to  each  ocher  by  a 
'Modular  Attitude  Control  System  bus'  (MACS-bus). 
The  AOCS  subsystem  is  connected  to  the  ocher  units 
if  Che  satellite  via  an  'On-Board  Data  Handling 
bus'  (OBOH-bus). 


Rg.  2  Simplified  block  diagram  of  the  SAX  AOCS 


The  AOCS  Is  controlled  by  software  running  in  the 
ACC.  This  software  is  divided  into  two  packages: 

-  Basic  Software  (BSW).  developed  by  Alenia  Spazio 
that  provides  operating  system  services  and 
basic  interface  services  to  the  MACS  and  OBDH 
busses.  It  hides  the  ACC  hardware  peculiarities 
for  the  Application  Software. 

-  Application  Software  (ASW) ,  developed  by  NLR. 
This  software  provides  all  attitude  control 
tasks  and  manages  Che  application-dependent 
communication  with  the  ground  (via  the  OBDH)  and 
with  the  AOCS  units. 


The  basic  requirements  on  the  AOCS  and  hence  on  the 
ASW  software  are  to  provide  the  capability  to: 

-  Command  the  Zc-axis  (main  instrument  axis)  of 
SAX  to  any  direction  (within  the  pointing 
constraints)  with  an  accuracy  of  90"  and  the  Yc - 
axis  with  an  accuracy  of  16.3  arcmln.  The 
commtanded  attitude  must  be  maintained  during 
pointing  periods  of  maximal  28  hours. 

-  Safeguard  the  satellite  against  violation  of  the 

safe  pointing  domain.  This  safe  pointing  domain 
is  defined  mainly  by  the  fact  that  the  main 
scientific  instrument,  the  Narrow  Field 

Instrument  (NFI),  will  be  destroyed  by 

(indirect)  radiation  from  the  sun.  Therefore, 
Che  angle  between  the  Zc-axls  of  the  satellite 
and  the  sunvector  must  be  at  least  60* . 

-  Autonomously  acquire  and  maintain  a  safe 
attitude  when  no  ground  commanding  is  available 
and  after  safeguard  violations. 

-  Process  ground  commands  and  generate  relevant 
telemetry  for  health  checking  on  the  ground  and 
for  attitude  reconstruction  In  relation  with  the 
processing  of  the  acquired  scientific  data. 

Due  to  the  high  sensitivity  of  the  main  scientific 
instrument  to  sun  radiation,  the  correct  execution 
of  the  ASU  is  critical  for  the  success  of  the 
mission.  Therefore,  it  has  to  be  highly  reliable 
and  measures  have  to  be  implemented  to  ensure  Che 
survival  of  the  satellite  under  all  foreseeable 
single  point  failure  conditions.  On  the  other  hand, 
previous  experiences  have  learnt  that  such  software 
shall  also  be  flexible  and  adaptable  to  new 
requirements  and/or  unexpected  situations  during 
Che  mission.  Due  to  this  type  of  flexibility  the 
missions  ANS  (also  an  X-ray  mission)  and  IRAS 
(Infrared  research)  were  highly  successful.  Without 
this  flexibility,  both  missions  would  have  been 
..argely  or  completely  failed  (Refs.  3  and  4).  In 
scientific  missions  like  these,  the  scientific  data 
obtained  can  lead  to  requests  for  new  observation 
types  or  for  changes  in  existing  observation  types. 
It  can  also  appear  that  the  sensors  and/or 
actuators  used  show  unexpected  behaviour,  which  has 
to  be  compensated  for  in  the  AOCS  software. 
Therefore  the  need  exists  that  updated  versions  of 
the  software  can  be  uploaded  (via  the  telecommand 
channel)  into  the  ACC  during  the  mission. 

4.  DESIGN  MEASURES  TO  MEET  THE  REQUIREMENTS 

In  a  combined  hardware/sof tvare  system,  both 
hardware  and  software  failures  have  to  be  taken 
into  account  for  a  reliable  design.  The  result  of 
hardware  failures  can  be  assessed  via  a  traditional 
Failure  Mode  Effect  Analysis  (FMEA). 

NLR  research  to  take  also  software  failures  into 
account  in  a  FMEA  analysis  (Ref.  S)  has  learnt  that 
r*'ndom  software  failures  (such  as  random  addressing 
the  memory)  are  difficult  to  handle  in  this  respect 
as  the  effect  of  such  failures  cannot  be  predicted. 
One  conclusion  of  this  study  was  that  the  design  of 
the  hardware/software  system  has  to  be  such  that 
the  safety  critical  software  is  protected  against 
such  random  failures.  For  SAX,  the  following  design 
measures  have  been  taken: 

*  The  ASW  software  has  been  divided  into  two 
parts : 

-  Basic  Attitude  Control  (BAG)  software.  This 
part  is  highly  reliable  and  safe.  It  will  be 
(initially)  stored  in  Read  Only  Memory  (RCW) 
in  the  ACC,  together  with  the  BSW.  Main 
purpose  of  this  software  is  to  provide  the 
functionality  needed  to  acquire  and  keep  a 
safe  satellite  attitude  after  power-up  and 
fallback.  Furthermore  it  contains  the  data 
handling  functions  needed  to  submit  the  state 
of  the  AOCS  to  the  ground  and  to  give  the 
control  over  (on  ground  coausand)  to  the  EAC 


software.  After  a  fallback  to  the  BAG 
software,  the  ground  operations  teasi  can 
analyse  the  reason  for  fallback  and  devise 
solutions  to  circuBvent  this  reason. 

•  Extended  Attitude  Control  (EAC)  software.  This 
software  provides  all  functions  required  for 
the  AOCS,  Including  the  control  laws  for 
accurate  scientific  pointings  and  the 

generation  of  full  attitude  reconstruction 
teletsetry.  EAC  is  stored  in  Random  Access 
Heaory  (RAH)  of  the  ACC  and  can  be  loaded 
and/or  modified  on  ground  command. 

*  The  6086  facilities  to  separate  code  from  data 
are  used  extensively.  These  facilities  provide  a 
hardware  protection  against  overwriting  the  code 
segment  by  the  application  software. 

*  The  behaviour  of  the  software  is  checked  by  a 

hardware  ACC  watchdog  monitor.  This  monitor  has 
to  be  triggered  at  least  once  per  two  seconds 
with  a  correct  bit  pattern.  If  it  receives  a 
wrong  bit  pattern,  or  if  it  is  not  triggered  at 
all.  It  forces  an  ACC  power>up  initialisation 
sequence  and  hence  a  fall  back  to  the  BAC 

software.  This  watchdog  monitor  protects  the 
system  against  failures  like  endless  loops  or  a 
cooiplete  halt  of  the  software. 

*  A  similar  watchdog  is  implemented  outside  the 

ACC.  This  watchdog  is  located  in  the  Monitoring 
and  Reconfiguration  Unit  (MRU).  The  ASU 

regularly  has  to  read  a  checkword  from  this  unit 
via  the  MACS  bus,  change  one  bit  in  this 

checkword,  and  send  It  back  to  the  MRU.  If  the 
MRU  detects  that  no  checkword  has  been  received 
back  for  six  seconds,  it  will  force  a  switch 
over  to  the  cold  standby  ACC  unit.  This  monitor 
protects  against  failures  in  the  ACC  hardware 
and  within  the  MACS  bus  hardware.  It  also 

prevents  chat  repeated  Initialisation  of  the 
active  ACC  by  the  ACC  watchdog  leads  to  loss  of 
attitude  control. 


*  For  reasons  of  power  consumption,  the  BAC 
software  cannot  be  executed  from  ROM  directly. 
Therefore,  it  is  copied  to  RAM  as  part  of  the 
ACC  power-up  iniclallsation  sequence.  In  order 
to  check  that  the  copy  of  the  software  is  not 
corrupted  during  execution,  a  checksum  check  is 
executed  twice  a  second  on  the  copied  code.  If 
this  check  fells,  the  ACC  is  forced  to  execute  a 
power-up  Initialisation  sequence,  by  a  false 
trigger  of  the  ACC  watch  dog. 

*  During  the  execution  of  the  EAC  software,  a 

separately  coded  safeguard  function  is  executed 
every  half  second.  This  safeguard  function 
checks  chat  the  behaviour  of  the  satellite 
remains  within  the  safety  limits.  If  the 
attitude  becomes  unsafe,  the  ACC  is 

reinitialised  via  the  ACC  watch  dog.  leading  to 
a  fallback  to  the  BAC  software.  The  safeguard 
software  la  executed  In  the  context  of  a  special 
interrupt.  In  this  way,  the  safeguard  code  will 
be  executed  regardless  of  the  current  state  of 
the  EAC  software.  The  safeguard  criteria  have 
been  designed  as  simple  and  robust  as  possible 
In  order  to  ptevenc  errors  In  the  safeguard 
code . 

The  reliability  of  the  ASW  has  been  designed- in  by 
the  strict  application  of  interface  control 
mechanisms  and  configuration  control  measures. 
Interface  control  has  been  executed  during  the 
design  by  application  of  the  Teamwork  package 
(refer  to  section  4).  For  the  coding  phase,  we  have 
copied  Che  Ada  'package'  mechanism  to  the  ASU 
Implementation  language  C.  Every  module  in  the  ASU 
has  been  declared  by  a  header  file  (that  defines 
the  module  prototype)  and  defined  in  a  code  file 
(chat  cc 'grains  the  actual  executable  code  of  the 
module).  Sitailarly.  every  shared  data  item  has  been 
declared  In  one  header  file  and  defined  in  one  code 
file.  A  module  that  calls  another  one  must 
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Fig.  4  Basic  architecture  of  the  EAC  sc^tware 


*#lnclude*  the  relevant  header  file,  which  ensures 
that  the  coopiler  can  check  the  correctness  of  the 
calls.  Siailarly,  Che  declaration  of  shared 
variables  has  to  be  included  in  all  nodules  that 
use  then.  The  header  files  are  derived  directly 
fron  the  Teaowork  database,  thus  ensuring  the 
coapatibility  between  the  detailed  design  and  the 
code.  All  files  are  under  control  of  the 
configuration  nanageoMnt  package  CADESE  (see 
section  A). 


The  perforaance  of  the  design  and  control  lavs  to 
be  lapleaented  by  the  ASV  has  been  checked  by  FSS 
during  extensive  sinulatlons  of  the  systen. 

The  required  flexibility  is  achieved  by  designing 
the  EAC  software  as  a  separate  independent  package , 
Chat  can  in  principle  execute  independent  of  the 
BAC  software.  The  functionality  of  the  EAC  software 
has  a  significant  overlap  with  the  BAC 
functionality  in  the  areas  of  cooaand  processing, 


t«l«MCry  g«n*raCion  Atid  unit  <Uc«  handling.  But  in 
ordar  to  b«  free  to  change  sofcwara  ralaced  to 
thaaa  aspects,  all  EAC  functions  have  been  designed 
as  separate  prograas ,  that  are  executed  independent 
of  the  EAC  programs.  Figure  3  contains  an  overall 
overview  of  the  ASV.  Figure  4  shows  the  structure 
of  the  EAC  software .which  Is  similar  in 
construction  to  the  BAC  software.  Both  packages 
implement  the  full  set  of  functions,  which  are 
executed  cyclically  twice  per  second: 

Initialisation  (performed  only  once); 

Control  calculations  (including  unit  handling 
and  actuator  commanding); 

Telemetry  generation  (House  Keeping  Data  and 
Attitude  Reconstruction  Data); 

Telecommand  processing; 

User  selectable  data  processing;  and 
Event  related  data  monitoring. 

The  Independence  of  the  EAC  software  means  that  for 
Instance  the  telemetry  processing,  which  is  nearly 
identical  for  BAC  and  EAC  is  designed  as  a  separate 
EAC  task.  In  the  current  design,  this  EAC  cask 
makes  extensive  use  of  the  routines  in  the 
corresponding  BAC  cask  In  order  to  save  memory 
occupation.  But  it  can  be  replaced  completk. ly  by 
software  chat  is  Independent  of  the  BAC  software 
and  Chat  implements  different  requirements,  if  chat 
would  be  necessary  during  the  mission.  This  would 
be  much  more  difficult  if  the  BAC  task  for 
telemetry  generation  was  used  completely  during  the 
execution  of  the  EAC  software. 

It  should  be  noted  chat  a  high  flexibility  of  the 
software  can  lead  to  a  decrease  of  the  reliability. 
During  the  mission,  the  temptation  can  be  high  to 
load  updated  software  chat  has  a  lower 
qualification  status  chan  the  original  EAC 
software.  The  design  measures  to  protect  the  BAC 
software  against  random  EAC  software  failures, 
however.  guarsntee  the  survivability  of  the 
mission,  even  if  this  software  is  replaced  by  lower 
quality  software. 


5.  CASE  TOOLS  IN  USE 

For  the  development  of  the  ASU.  a  development 
environment  has  been  purchased,  based  on  a  network 
of  four  HP  64000  workstations.  The  following 
development  tools  have  been  installed  on  this 
network: 

The  CADRE  Teamwork  package ,  that  has  been 
prescribed  by  the  prime  contractor  for  all 
parties  developing  on-board  software  for  SAX. 
Teamwork  has  been  used  to  Input  and  check  the 
Software  Requirements  and  the  Architectural 
Design.  It  supports  the  Structure  Analysis 
method  for  (real-time)  software  systems  as 
defined  by  Yourdon,  DeMarco,  Constantine  end 
Hatley.  The  requirements  and  architectural 
design  have  mainly  been  described  in  Data  Flow 
Diagrams  and  State  Transition  Diagrams.  The  data 
chat  is  handled  by  the  ASW  has  been  described  in 
detail  in  a  Data  Dictionary.  Teamwork  includes  a 
powerful  checking  option  to  ensure  the  internal 
consistency  of  the  thus  obtained  functional 
decomposition. 

The  Detailed  Design  of  the  ASU  has  been 
developed  using  the  Structured  Design  method, 
also  supported  by  Teamwork.  Each  individual  cask 
of  the  ASW  is  defined  with  one  Structure  chart 
and  a  number  of  Module  Specifications.  Also  for 
.  this  development  phase.  Teamwork  provides  a 
number  of  consistency  checks,  although  these  are 
less  powerful  than  the  checking  options  for  the 
Structured  Analysis  method. 

-  The  DeskTop  Publishing  package  Framemaker. 
Framemaker  la  an  Integrated  text  and  graphics 
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processing  tool  with  the  capability  to  import 
the  graphical  information  from  Teamwork  models 
Using  this  tool,  the  text  and  pictures  of  the 
design  can  be  quickly  combined  Into  complete 
documents  via  the  definition  of  generic 

document,  refer Ing  to  text  and  Teamwork  models 
CADESE.  The  tool  CADESE  (purchased  via  the  Dutch 
firm  ACE)  is  an  extension  of  the  standard  UNIX 
sees  facilities.  It  Is  used  for  the 
configuration  management  of  the  developed  code. 
CADESE  offers  version  control  to  maintain  the 
source  files  for  each  official  software  release 
and  to  ensure  that  earlier  versions  can  easily 
be  retrieved.  Furthermore.  It  is  able  to 
generate  UNIX  'make'  files  for  each  release, 

such  chat  the  binary  code  can  be  generated 
automatically  after  each  change. 

In  addition,  a  number  of  tesctools  have  been 
purchased,  or  have  been  developed  especially  for 
the  ASU  development.  These  cesttools  are  not 
considered  as  real  CASE  tools,  but  they  are  of  the 
same  level  of  Importance  for  the  development  of  the 
software . 

-  8086/8087  Hardware  emulator.  This  emulator  is  In 
fact  a  real  8086/8087  processor,  enhanced  with 
options  CO  control  the  memory  contents  and  the 
execution  from  within  the  HP  development  system. 
Software  emulator  of  the  8086/8087  processor  on 
the  HP  64000  development  system.  This  emulator 
was  used  mainly  for  the  individual  module  tests, 
after  module  tests  executed  in  the  native  C 
environment  on  the  HP  system.  The  use  of  the 
emulator  ensures  chat  the  nodules  tested  in  the 
HP  native  environment  will  also  execute 
correctly  in  the  target  processor.  Also,  this 
software  emulator  decreased  the  work  load  on  the 
hardware  emulator . 

-  The  ACC-Command-Cenerator  is  a  program  running 
on  the  HP  development  system  and  interacting 
with  Che  user.  It  generates  ACC  teleconmands  in 
human- readable/edi cable  form  in  user  specified 
ACC-Command-Files .  Via  a  menu-based  Interface 
the  user  can  select  new  ACC-Commands  Co  be 
generated,  and  specify  their  parameters.  The 
program  can  run  In  checking  mode  and  In  non¬ 
checking  mode.  In  the  checking  mode  all  ACC- 
Coimaand  parameters  are  enforced  to  be  valid.  In 
the  non-checking  mode  these  enforcements  are 
left  out.  so  that  Illegal  ACC -Commands  can  be 
generated  in  the  ACC -Command' Files . 

-  The  TMTC-Slmulator  is  a  program  running  on  the 
HP  development  system  and  interacting  with  the 
BSW- Simulator  (which  simulates  the  BSW 
behaviour).  From  the  standard  Input  stream  it 
reads  ACC  Commands  from  a  redirected  ACC- 
Command-Flle  as  generated  by  the  ACC-Command- 
Generator.  and  passes  these  to  the  BSU- 
Simulator.  It  reads  telemetry  buffers  passed  by 
Che  B$U-Simulator .  and  displays  these  in  human- 
readable  form.  The  program  also  can  run  in 
cheeVing  mode  and  in  non-checking  mode. 

-  SATSIM  is  a  program  running  on  the  HP 
development  system  and  Interacting  with  the  BSV- 
Slmulator.  It  simulates  the  SAX  sensors, 
actuators  and  dynamics.  Using  this  program, 
closed  loop  integration  tests  have  been 
executed. 

-  The  BSU-Slmulator  is  a  program  running  on  the 
Intel  8086  emulator  system  and  Interacting  with 
the  user,  the  ASW,  the  TMTC-Slmulator  and 
SATSIM.  It  simulates  the  Basic  Software.  The 
BSW- Simulator  was  needed  because  the  BSW  is 
developed  in  parallel  with  the  ASW.  The 
simulator  Is  a  very  simplified  version  of  the 
BSW  with  the  emphasis  on  the  properly  modelling 
of  the  ASW/BSW  Interface. 


6.  advantages  and  disadvantages  of  using  case 
TOOLS 

During  cha  daalgn  of  Cha  ASW,  a  number  of 
advantages  and  disadvantages  of  cha  cools  used  have 
bean  recognised  (in  comparison  with  the  manual 
application  of  chc*  structured  methods). 

A  main  advantage  of  cools  like  Teamwork  is  the 
existence  of  automated  checks  that  can  be  done  on 
Che  design.  These  checks  guarantee  the  internal 
consistency  of  the  design  models  (functions  and 
dataflows)  of  the  software.  Oecomposicion  of  a 
function  with  its  dataflows  into  a  sec  of  lower 
level  subfunctlons  can  be  done  without  introducing 
inconsistencies  between  the  various  design  levels. 
This  point  is  especially  important  during  the 
(iterative)  initial  design  of  a  model.  The 
consistency  checks  enable  a  more  detailed 
decomposition  of  the  model.  Our  experience  is  that 
we  could  add  two  or  three  levels  to  the  design 
hierarchy,  without  losing  control  over  the  design. 
In  this  way,  more  design  details  could  be 
formalised  (and  checked)  cn«tn  in  previous  projects, 
leading  to  an  Increased  quality  of  the  design. 

It  should  be  noted,  however,  that  the  checks  that 
are  possible  for  Structured  Analysis  models  are 
more  powerful  than  chose  for  Structured  Design 
models.  This  is  mainly  due  to  the  fact  chat  SD 
models  are  not  hierarchically  leveled. 

The  guarantee  of  internal  consistency  also  enables 
a  more  safe  implementation  of  design  changes.  The 
addition  or  deletion  of  a  dataflow  on  a  low  level 
of  decomposition  has  to  be  reilected  also  in  the 
higher  levels  where  appropriate.  Tools  like 
Teamwork  do  not  allow  that  loose  ends  are  left  in 
the  design,  like  data  that  is  used,  but  never 
generated.  The  manual  application  of  the  used 
methods  imposes  rises  in  this  area.  In  our 
situation.  FSS  developed  the  detailed  functional 
design,  while  NLR  was  developing  with  the  detailed 
software  design  (Ref.  6).  This  approach  was 
necessary  in  order  to  optimise  the  development 
schedule,  but  it  would  have  been  Impossible  without 
the  Teamwork  tool,  due  to  the  iterative  nature  of 
this  approach. 

The  coad>ination  of  Teamwork  with  a  desktop 
publishing  tool  has  led  to  a  fast  document 
production  process.  The  contents  of  a  document,  for 
instance  the  Architectural  Design  Document,  has 
been  defined  In  terms  of  text  portions  and  the 
Teamwork  model  identification  of  the  design  model. 
Using  a  specialised  interface  tool  between  Teamwork 
and  Framemaker,  the  text  and  graphics  of  the 
documents  can  be  automatically  combined  into  one 
printed  document.  This  integrated  approach  enabled 
us  to  produce  a  complete  issue  of  design  documents 
within  one  working  day.  In  comparable  previous 
projects,  such  production  could  take  one  week  or 
more  and  led  to  lower  quality  documents. 

A  final  advantage  of  the  use  of  a  computer  aided 
tool  to  support  the  design  method  is  that  changes 
to  the  design  can  be  (and  in  the  Teamwork  approach 
is)  logged  and  identified.  Every  issue  of  a  Data 
Flow  Diagram  can  be  saved  and  is  accompanied  by  a 
status  record.  This  information  can  be  of  help  to 
determine  Che  cause  of  unexpected  errors.  Old 
Issues  can  be  used  as  backup  information  and  in 
cause  of  unexpected  problems  the  cause  can  be 
traced  back. 

A  similar  advantage  can  be  mentioned  for  the  use  of 
the  CADESE  configuration  management  package. 
CADESE.  together  with  the  well-known  SCCS  software, 
logs  all  changes  to  coded  modules  and  includes 
facilities  Co  roll  back  co  earlier  versions.  CADESE 


Includes  an  ucilicy  co  generate  a  proper  'make¬ 
file'  for  the  software,  chat  includes  all  file 
dependencies.  This  utility  guarantees  that  the 
proper  version  of  all  code  files  is  used  to  produce 
binary  load  images  of  the  code.  Interface  problems 
chat  can  easily  occur  by  using  invalid  (outdated) 
precompiled  object  files  are  thus  eliminated, 
wlchouc  raising  the  burden  to  compile  all  sources 
each  time  a  new  load  image  Is  needed. 

A  disadvancage  chat  we  encountered  was  that  the 
application  of  a  tool  like  Teamwork  Is  likely  co 
become  a  design  goal.  In  a  project  where  the 
methods  are  applied  manually,  it  Is  natural  to 
deviate  from  the  formal  definition  of  the  methods 
in  chose  cases  where  such  formalism  would 
unnecessarily  restrict  the  designers.  When  a  Cool 
is  used  to  check  the  obedience  to  formal  rules, 
such  deviations  are  not  allowed  the  designers  are 
tempted  to  define  tricky  work  arounds,  just  to 
satisfy  the  method  checker.  It  appeared  difficult 
to  regard  the  cool  just  as  a  tool  and  not  as  a 
design  goal. 

Similarly,  the  availability  of  powerful  graphical 
editing  facilities  on  the  diagrams  tempts  the 
designers  to  spend  (lose)  time  in  the  esthetical 
optimisation  of  these  diagrams.  Such  optimisation 
does  not  improve  the  design,  nor  does  it  increase 
Che  quality  of  the  documentation.  It  is  difficult 
CO  recognise  these  temptations  and  to  counteract 
them  during  the  development. 

7.  PRACTICAL  PROBLEMS  ENCOUNTERED  WITH  THE 
APPLICATION  OF  CASE  TOOLS 

During  the  development  of  Che  ASU  software,  a 
number  of  practical  problems  have  been  encountered 
with  the  application  of  the  used  tools.  These 
problems  are  reported  such  chat  cool  developers  can 
enhance  their  products.  Unless  explicitly  stated, 
it  is  our  opinion  that  the  reported  problems  are 
not  specifically  related  to  Che  Teamwork  tool .  but 
have  a  more  general  nature. 

The  major  problem  enc  >untered  is  the  absence  of  a 
coupling  between  the  Structurfd  Analysis  and  the 
Structured  Design  method.  These  methods  cannot  be 
used  In  an  Integrated  way  in  one  model,  such  that 
automated  checks  of  the  detailed  design  (modelled 
using  the  SD  method)  against  the  architecture 
(modelled  using  the  SA  method)  can  be  executed.  The 
absence  of  such  checks  counteracts  the  advantages 
of  using  these  methods  in  relation  with  an 
automated  tool . 

From  a  software  developers’  point  of  view,  it 
should  be  possible  to  define  a  low-level  (SA) 
process  in  the  form  of  a  (SD)  structure  chart  with 
related  module  specifications. 

Another  problem  was  the  rigor  with  which  the 
configuration  management  of  models  has  been 
implemented.  Our  basic  approach  in  developing  the 
ASV  architecture  has  been  to  define  the  task 
structure  as  'baselined'  model.  (A  baselined  model 
cannot  be  changed,  unless  its  owner  removes  the 
'baseline*  status.)  Thereafter.  the  individual 
developers  detail  one  or  more  processes  of  this 
model  In  a  private  'incremental'  model  of  the 
baseline.  This  approach  allows  multiple  developers 
to  work  Independent  of  each  other  in  parallel. 
However,  after  definition  of  Incremental  models  to 
a  baselined  model,  the  'baseline*  status  cannot  be 
removed,  so  there  is  no  way  at  all  to  change  the 
latter  model.  This  has  as  result  that  errors  or 
omissions  cannot  be  corrected  in  the  baseline,  but 
have  to  be  corrected  In  all  separate  incremental 
models  individually. 

Furthermore,  the  Incremental  models  cannot  be 
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lntiifr«t«d  in  ch«  b«««Iin«  aodvl  icseif,  but  have 
to  b«  Intograted  Into  another  Increaental  ttodel  of 
the  baseline,  which  can  then  be  the  baseline  for 
further  developaent.  This  results  in  an  artificial 
hierarchy  of  dependant  «odels  chat  Is  not  suited  to 
explain  the  current  design  status  after  a  nui^er  of 
iterations . 

Our  (pragBstic)  approach  has  been  to  make  baselined 
Models  'complete*  (which  means  that  all 
dependencies  to  the  parent  model  are  repMved  by 
copying  the  information  of  that  model  Inco  the 
current  model)  and  link  completed  models  to  a  dummy 
(empty)  model.  In  this  way  several  issues  of  a 
baselined  model  can  be  controlled  at  the  same  level 
of  model  hierarchy. 

The  rigorous  configuration  isanagement  has  also  led 
to  the  decision  chat  the  architectural  design  of 
the  ASU  would  be  documented  in  another  model  chan 
the  detailed  design.  Both  models  own  their  private 
data  dictionaries  chat  define  the  same  dataflows. 
Only  rigid,  but  manual,  configuration  control 
procedures  can  ensure  the  compatibility  of  these 
data  dictionaries. 

A  practical  difficulty  with  Teamork  (but  probably 
with  more  tools)  has  been  that  process 
specifications  and  module  specifications  have  to  be 
defined  in  a  textual  form.  It  Is  not  possible  to 
define  a  specification  in  a  graphical  way.  for 
instance  in  the  form  of  a  Nassi'Shneiderman  chart 
(Ref.  7).  We  have  used  a  very  simple  form  of  pseudo 
code  for  the  module  specifications  to  compensate 
for  the  absence  of  graphical  representation  of 
detailed  module  logic. 

Furthermore,  the  text  editing  capabilities  of  the 
tool  are  rudimentary  and  limited  to  individual 
model  “ntries  (data  definitions.  process 
specifications,  etc.).  No  options  exist  for 
instance  to  change  a  certain  term  In  all  P-specs  or 
M'specs  with  one  command. 

Improvements  in  these  areas  will  prove  very  helpful 
for  software  developers. 

8.  OmRENT  PROJECT  STATl'S 

All  ASW  software  has  been  coded  and  module  tested. 
The  BAG  software,  consisting  of  ±  9000  lines  of 
executable  (non*comment)  C-code,  has  been 
integration  tested  by  the  development  team  in  the 
development  environment.  During  these  integration 
tests,  the  software  requirements  were  verified. 
After  that,  the  software  has  been  subjected  to  a 
number  of  validation  tests  executed  by  an 
independent  test  team.  The  validation  tests 
involved  closed-loop  real-time  tests  of  the 
software  running  in  a  "Functional  MOdel"  (FUMO)  of 
the  ACC  computer.  The  ACC  environment,  including 
Che  satellite  dynamics  and  Che  unic  behaviour,  was 
simulated  as  realistic  as  possible.  During  these 
tests,  all  relevant  User  Requirements  for  the  BAC 
software  were  checked.  During  the  validation  tests 
a  total  of  5  errors  have  been  identified  in  the  BAC 
code  under  test.  The  majority  of  these  errors  has 
been  traced  to  late  requirement  changes,  which  were 
not  implemented  completely,  or  led  to  unexpected 
side  effects. 

After  the  validation  tests,  the  BAC  software  has 
been  formally  delivered  to  Alenla  for  used  in  the 
AOCS  subsystem  integration  process,  where  the  ACC 
is  integrated  with  the  real  units.  During  these 
tests,  no  errors  in  the  code  have  been  Identified 
yet. 

The  EAC  software,  consisting  of  ±  5000  additional 
lines  of  executable  C-code  is  being  integration 
tested  by  the  development  team.  The  independent 
validation  tests  of  this  software  has  been  started. 


9.  USSONS  LEARMT 

During  application  of  Che  described  CASE  cools,  a 
number  of  lessons  have  been  learnt  chat  seem  to  be 
valuable  for  fucure  developments. 

The  application  of  an  automated  tool  to  support 
the  Structured  Analysis  and  Structured  Design 
methods  during  the  design  increases  the  quality 
of  the  software  design  and  thus  contribute  'o 
the  overall  success  of  the  mission.  However, 
does  not  lead  to  a  decrease  in  design  cose. 

In  case  a  larger  Structured  Analysis  model  is 
developed  by  a  number  of  team  mead>ers  in 
parallel.  It  is  Important  to  define  a  number  of 
standards  to  be  adhered  to.  Such  standards 
should  at  least  cover  topics  like  naming 
conventions  for  processes  and  dataflows;  use  and 
docuMntatlon  of  control  signals  (tiiggers 
and/or  levels);  pseudo  code  to  be  used  inside 
process  specifications  and  the  overall  layout  of 
Che  DFD's. 

During  the  development  of  a  Structured  Analysis 
model  of  a  complex  piece  of  realtime  software. 
Che  design  of  the  dataflows  is  as  important  as 
Che  design  of  the  processes.  Ignorance  of  this 
can  lead  to  the  situation  chat  various  parts  of 
the  model  use  effectively  Che  same  dataflows, 
but  define  them  from  different  viewpoints.  This 
can  Increase  the  model- integration  effort. 

In  a  multinational  project  whtre  a  number  of 
firms  cooperate  to  develop  a  large  integrated 
software  system,  the  application  of  cools  should 
be  considered  as  early  as  possible.  It  is 
advantageous  when  all  firms  cooperating  within 
the  same  project  use  the  same  toolset.  This 
leads  to  a  common  understanding  of  the  applied 
methods  and  to  exchangeability  of  software 
models.  However,  application  of  the  same  toolset 
does  not  guarantee  that  the  various  models  of 
parts  of  the  software  can  be  simply  integrated 
into  one  overall  model.  If  this  Is  needed  or 
required,  it  should  be  clear  from  the  beginning. 
Vhen  a  source  code  management  Cool  like  CADESE 
Is  used,  it  is  necessary  that  it  is  available 
during  Che  whole  project  and  on  all  computers 
where  the  software  has  to  be  compiled  and/or 
modified.  Only  Chen  it  can  be  ensured  that  only 
authorised  changes  are  made  to  the  software. 

Alchou^  some  negative  points  have  been  mentioned 
in  this  paper,  the  final  conclusion  is  Chat  the 
application  of  CASE  tools  In  this  type  of  projects 
is  an  important  contribution  to  the  quality  of  the 
developed  software. 
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Discussion 


Question  D.  NAIRN 

Would  your  tools  and  techniques  sclae  up  to  a  much  larger  project  team? 

Reply 

The  old  manual  methods  allowed  2-3  persons  to  cooperate  in  software  design.  With  automated  design  tools,  this  will 
scale  up  to  10-15  persons. 

Note  that  to  cooperate  is  meant  to  be :  technical  people  working  together  on  a  design  without  imposing  a  management 
hierarchy  on  top  to  grant  compatibility  between  different  groups. 
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summary 

HOOD  represenis  one  of  the  most  interesting 
approaches  of  the  recent  years  to  suppmt  an  object 
oriented  SW  design  for  large  embedded  systems  wrinen 
in  Ada. 

This  paper  reports  about  experiences  gained  by  the 
authors  in  the  context  of  a  current  large  european 
avionic  developement  project,  where  the  Ada  SW 
design  has  been  performed  using  HOOD  Version  3.0. 

A  simplified  example  describes  the  approach  taken  in 
the  project  for  SW  architectual  design.  A  critical 
evaluation  of  the  HOOD  method  follows,  whae 
advantages  and  disadvantages  are  discussed  and  some 
hints  are  given  to  overcome  some  identified  weak  areas. 

The  paper  concludes  with  the  recognition  of  HOOD  as  a 
promising  approach  and  encourages  further  discussion 
to  remove  the  weak  areas. 

1.  INTRODUCTION 

This  report  will  give  an  overview  on  experiences  gained 
with  the  HOOD  SW-Design  method  during  SW- 
Develqpmeni  for  a  large  complex  avionic-system. 

Avionic-systems  in  general  ate  complex,  time-critical  in 
their  behaviour  and  have  severe  safety  requirements, 
since  malfunctions  could  affect  human  life  and  can 
cause  lost  of  the  aircraft.  To  fullfil  the  high  quality, 
performance  and  safety  requirements,  a  well  defined, 
controlled  development  process  must  be  established. 
This  will  include  methods,  tools  and  implementation 
languages. 

For  avionic  software  development  Ada  has  been 
selected  as  implementation  language  and  object- 
oriented  methods  are  a  most  promising  approach  for  the 


architectural  design.  In  our  project  the  HOOD  method 
has  been  selected,  which  has  been  originally  specifically 
developed  for  the  'architectural  SW -design'  of  Ada  SW- 
Sy  stems. 

We  will  describe  the  'architectural  design'  approach,  our 
experiences  with  HOOD  and  Ada  and  we  will  give 
some  hints,  which  can.  in  our  opinion,  help  to  overcome 
some  of  the  method's  shortcomings. 

The  report  will  include  the  following  areas; 

Inject  overview 

Intrixluctton  to  the  HOOD  method 
the  architectural  design  process 
Evaluation  of  the  HOOD  method 
Recommendations  and  conclusions. 

Finally  it  should  be  emphasized  that  this  paper  reflects 
only  the  personal  experiences  and  opinions  of  the 
authors. 

2.  THE  PROJECT 

The  project  is  a  large  european  avionk-system 
development,  scheduled  to  be  completed  at  the  end  of 
the  nineties.  The  overall  system  has  been  subdivided 
into  several  subsystems,  which  are  developed  under 
respon.sibilitv  of  the  participating  nations. 

The  development  process  is  based  upon  the  DOD-STD- 
2167  life-cycle  model,  which  has  been  tailored  to  the 
specific  project  requirements.  The  on-board  target 
computers  are  multi-processors,  based  on  the  Motorola 
68020  processor.  The  software  has  been  developed  in 
Ada  with  the  DEC- Ada  compiler  on  the  host  and  the 
XD-Ada  cross-compiler  for  the  Motorola  targets. 

For  the  'architectural  SW-Design’  the  HOOD  method 
version  3.0  (HOOD  Reference  Manual.  Sept.  1989)  has 
been  used.  The  SW-Specifications  have  been  produced 
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in  a  SADT-like  form  supported  by  a  (paphic  tool  and 
pseudocode  fur  algoriiluns. 

The  HOOD  experiences.  leferenced.  are  derived  from 
development  of  a  50  K-SLOC  SW-package. 

The  example  used  in  (he  presentation,  will  show  a 
simplified  system-model,  but  nevertheless  it  is  suitable 
lor  describing  the  HOOD  experiences.  The 
simpiitkation  will  also  elTect  the  un-board  target 
computer,  were  a  single  processor-system  has  been 
assumed,  instead  of  the  originai  multi-prucessor-system. 

3.  H(K>D  METHOD  OVERVIEW 

3.1  HISTORY 

HOOD  (Hierarchical  Object  Oriented  Design)  was  first 
developed  in  1987  as  the  result  of  a  study  contracted  by 
ESA.  Aim  of  the  study  was  the  definition  of  a  method  to 
support  the  architectunil  design  for  Ada  in  large 
embedded  software  development  projects. 

In  1989  the  evaluation  of  the  first  user  experiences  led 
to  a  revision  of  the  method  as  defined  in  the  HOOD 
Reference  Manual  Issue  3.0.  This  version,  almost  fully 
tool  supported,  was  used  in  our  project.  Further 
extensions  to  the  HOOD  definition  are  still  under 
discussion. 

3.2  DESIGN  PROCESS  AND  SEMANTICS 

Main  features  of  the  HOOD  method  are  ; 
top-down  iterative  process 
well  formalised  steps  for  design  and 
documentation 

supporting  techniques  for  object  identification 
hierarchical  software  system  model 
support  for  automatic  code  generation. 

At  the  beginning  the  whole  system  is  first  consideied  as 
a  root  object  and  then  decomposed  into  a  certain 
number  of  so  called  child  objects,  which  implement  the 
parent's  functionality.  To  implement  this  functionalities, 
the  child  object  can  call  the  operations  of  other  child 
objects. 

Therefore  (wo  kinds  of  relations  can  connect  HOOD 
objects: 

'include'  relationship  or  'parent/child'  relationship 
A  child  object  implements  a  part  of  the 
functionality  of  (he  parent  and  is  graj^caJly  con 
tained  in  the  body  of  the  parent  itself. 

'use'  relationship  or  'senior/junior’  relationship 


A  senior  object  calls  an  operation  of  the  juiuor 
object.  An  arrow  cormecis  graphically  the  senior 
and  the  junior  object  (fig.  3- 1 ). 

In  the  next  design  stage  each  child  object  becomes  a 
parent  and  is  decomposed  into  children  of  the  following 
logical  level.  Each  parent's  upcration  is  thereby 
connected  through  an  'Implemented.by'  hnk  with  ihat 
operation  of  the  child,  which  lakes  over  the 
implementation  of  the  operauon  functionality  (dashed 
line  in  tig.  3- 1 ). 

The  decomposition  process  is  repeated  for  each 
identified  child  object,  as  far  as  (heir  structure  becomes 
so  simple  that  they  can  be  considered  as  termmal 
objects  and  directly  implemented  in  Ada  or  pseudocode. 
The  result  is  a  hierarchical  system  model  ( HOOD 
Design  Tree),  which  reproduces  the  include 
relationships  between  the  objects  (fig.  3-2). 

A  HOOD  object  has  a  name,  an  interf  ace  lo  the  outer 
world  and  a  body,  which  cannot  be  acces.sed  from  the 
outside. 

There  are  several  kinds  of  objects: 
passive  object 
has  no  own  control  flow 
active  object 

has  an  own  control  flow  and  reacts  to  external 
stimuli  dependant  upon  its  internal  state  through  so 
called  "constrained  operations" 
class  object 

an  instantiaiable  template 
environment  object 

an  interface  to  another  system  environment 
virtual  object 

can  be  associated  with  a  phy.sical  proces.sor 

in  order  to  decompose  a  parent  into  child  objects,  four 
activities  are  performed  in  each  design  stage,  which 
represent  the  BDS  (Basic  Design  Step): 

Problem  Definition 

analysis  of  the  context  and  SW  requirements  for 
the  object 

Development  of  the  Solution  Siateny 
textual  description  of  the  functional 
implementation  on  a  high  abstraction  level 
Formalisation  of  the  Strategy 
identification  of  objects  and  operations  and 
producing  the  HOOD  Diagram 
Formalisation  of  the  solution 

fmmal  definition  of  the  object  interfaces 
completing  the  Object  Description  Skeleton 
(ODS)  for  the  parent 


filling  in  the  interface  fields  in  the  ODS's  of 
the  children 

justification  of  iiac  design  decisions 

Each  step  of  the  K*'"  decomposed  into  more  detailed 
subactivities. 

In  this  way  two  relevant  documents  are  produced  for 
-.ach  object: 

a  HOOD  Diagram 
anODS. 

The  ODS  (fig.  3-.^)  consists  of  several  fields,  which 
contain  a  semiformal  description  of  the  object  The  field 
OBCS  (Object  Control  Structure)  of  terminal  objects 
describes  with  Ada  .semantics  the  synchronisation  of  the 
operational  flows  and  their  interaction  with  the  internal 
stale  of  the  object  The  OPCS  fields  of  terminal  objects 
describe  the  sequential  opeiabon  flows  in  Ada  or 
pseudocixle. 

Additionally  to  the  HOOD  Diagram  and  the  ODS.  the 
HCS  (HOOD  Chapter  Skeleleton)  is  automatically 
produced  with  the  same  structure  as  the  BDS  itself. 

The  HCS  represents  the  object  documentation  and  can 
be  used  to  produce  the  design  documents. 

The  ODS  contains  all  relevant  information  about  the 
object  and  is  source  for  the  code  generation  process. 

The  code  generator  converts 
objects  in  Ada  packages 
OBCS's  in  tasks 

operations  in  procedures  or  funcuoas. 

Addiuonal  features  of  the  HOOD  semantics  are: 
description  of  synchronisation  properties  for 
constrained  operations  (interrupts,  limed.out, 
highly  or  loosely  synchronised) 
description  of  main  data  flows 
description  of  exception  flows. 

4.  ARCHITECTURAL  DESIHN 

4.1  PROBLEM  DOMAIN 

To  simplify  the  presentation  of  the  applied  method,  the 
problem  domain  has  been  reduced  to  a  few  essential 
functionalities. 

The  system  is  a  combat  aircraft  which  searches  for  air 
targets,  pursues,  visually  identifies,  engages  them  and 
has  a  missile  and  a  gun  as  weapons  and  a  radar  as 
sensor.  A  missile  and  a  gun  are  the  available  weapons, 
the  radar  is  the  sensor.  The  pilot  can  perform  a  pure 


visual  combat,  but  he  can  also  reipiite  system  support 
on  the  basis  of  navigation  and  radur  information. 

in  our  report,  we  will  focus  on  the  mission  part  of  the 
system. 

4J  METHODICAL  APPROACH 

Structured  development  tools  offer  a  practical  way  to 
conven  conventional  SADT-like  SW  specifications  imo 
an  object  oriented  design. 

In  the  Problem  Definition  Phase  the  SW  requirements 
are  restructured  by  applyuig  the  following  methods  and 
tools: 

DFD's  (Data  Flow  Diagrams)  for  the  descnption  of 
ilaia  flows  and  transform  processes 
STD's  (State  Transition  Diagrams)  for  the 
descnption  of  the  dynamic  behaviour 
Data  Dictionary  for  data  descnption. 

ERD's  (Entity  Relation.ship  Diagrams)  would  be  useful 
too  for  information  modeling,  but  were  not  supported  by 
our  development  tool.  Basic  strategies  fur  object 
oriented  design  are  applied: 

modeling  real  world  objects  at  high  logical  system 
levels 

grouping  DFD  transform  processes  around  the 

accessed  data  stores  to  suppon  definition  of 

abstract  data  types 

identifying  object  classes 

(in  our  case  only  paiameinc  instantiation  because 

of  the  ta-get  language  ADA). 

A  context  diagram  is  first  drawn  to  analyse  the 
environment  beyond  the  system  boundaries  (fig.  4-1). 

It  shows  the  real  world  as  it  appears  to  the  system 
analyst  and  how  the  SW  system  is  connected  via  a  data 
bus  interface  with  the  subsystems: 

Cockpit 

Radar 

NAV 

Armament  Control. 

The  DFD's  and  the  STD's  (fig.  4-2. 4-3. 4-4)  complete 
the  SW  specification  for  the  first  abstraction  level.  The 
SW  specification  model  focuses  on  the  objects  of  the 
real  world.  The  DFD  (fig.  4-2)  groups  the  main 
processes  and  data  flows  around  the  connected  physical 
subsystems  or  around  cockpit  displayed  items,  such  as 
list  of  the  designated  targets 
steering  cue. 


The  STD  (fig.  4-3)  shows  the  macro  states  of  the 
system,  is  disjuncl  lo  the  DFD  and  contributes  directly 
to  Htemify  design  objects  and  operations.  The  STD  (fig. 
4-4)4nstead,is  the  control  process  of  the  DFD  in  fig.  4-2 
and  is  to  be  balanced  with  it. 

The  following  considerations  prove  the  balance; 

Radar  Monitor  and  Radar  Correlation  are 
continuos  processes  and  do  not  appear  in  the  STD. 
Radar  Control.  System  TL  Update  and  Pilot's  TL 
Update  are  continuos  processes  loo.  but  they 
control  the  start/stop  of  Steering  Calculations. 
Missile  Envelope.  Missile  Control  and  Gun 
Calculations. 

Therefore  they  are  expected  to  appear  in  the  STD 
tor  generating  the  correspondem  events. 

The  events  Weapon  Selected  and  Weapon 
Deselected  are  generated  by  the  terminator 
Armament  Control. 

STD  actions  correspond  to  DFD  processes  or  parts 
of  them. 

Object  candidates  and  operations  are  ideniified  from  the 
the  spc«.ifit4Uion  model.  Crucial  items  for  object 
identification  are  terminators  and  data  .stores  m  the 
DFD’s  and  states  in  the  STD's. 

Fig.  4-5  highlights  the  objects  candidates  RADAR. 
TARGETS.  STEER_CUE  and  WEAPONS  by  enclosing 
the  corresponding  DFD  areas  into  a  dashed  frame. 

The  data  stores,  the  data  dictionary  and  the  data  flows 
provide  information  about  the  object  state  and  the 
contents  of  the  exchanged  messages.  Since  we  already 
developed  our  essential  strategies  for  an  object  oriented 
design  during  the  Problem  Definition  Phase  by 
restructuring  the  SW  specification,  in  the  next  design 
stage.  Development  of  the  Solution  Strategy,  we  simply 
prixluce  a  text  to  explain  the  models. 

The  result  from  the  Formalisation  of  the  Strategy  is 
shown  in  the  HOOD  diagram  in  fig.  4-6.  The  objects 
RADAR.  WEAPONS.  TARGETS  and  STEER_CUE 
represent  entities  of  the  real  world  and  conespond  lo 
object  candidates  of  the  solution  .strategy.  The 
INIT_STATE  object  represents  a  system  macro  stale  we 
identified  with  the  STD.  The  BUS  object  Ls  a  model  for 
the  bus  interface  from  the  context  diagram. 

Constrained  operations  are  marked  by  a  trigger  arrow 
on  the  H<X)D  diagram.  They  were  identified  by 
analysing  system  synchronisation  issues.  The  identified 
constrained  operations  determine  the  active  status  of  the 
objects  and  implicitely  the  processes  of  the  system. 


The  operations  lNrr_STATE.power_on, 
lNrT_STATE.power_off  and  BUS.get_bus_dala  are 
designated  as  ASER.byJT  constrained  operations, 
because  they  represent  system  interrupts  activated  by 
the  external  events  power  on.  power  off  and  new  bus 
data  available. 

Operations  which  have  to  preserve  the  conseaency  of 
accessed  data  structures  are  to  be  designated  as 
constrained.  This  is  the  case,  for  instance,  for 
TARG ETS. designate. trgt  and  TARGETS. updaie.hst. 
which  access  the  list  of  the  designated  targets  following 
the  pilot's  demands  or  target  information  passed  by  the 
radar  respectively. 

Other  operations  are  identified  to  be  constrained, 
because  of  their  concurrent  nature  with  other  system 
operations.  This  applies  to  the  constrained  operations  of 
STEER.CUE  and  WEAPONS,  which  implement 
concurrent  algorithms. 

Operauons.  which  run  inside  the  control  How  of  other 
operations,  are  designated  as  pa.s.sive  operatams. 
Therefore  all  the  imt  operauons  (except  BUS.init)  are 
pa.ssive.  because  they  run  sequenually  m  the  control 
flow  of  lNIT_STATE.power_on. 

The  operation  BUS.det_output_data  converts  the  system 
d.tta  into  the  bus  format  and  Ls  called  whenever  new 
system  data  have  been  calculated.  The  BUS  object 
contains  a  cyclic  background  process,  which  transmits 
the  output  data  lo  the  bus  and  raises  a  bus  error 
exception,  if  no  bus  data  arrive  within  a  predefined  time 
interval.  This  background  process  can  be  considered  as 
the  cyclic  portion  of  the  operation  BUS.init. 
Consequently  the  bus  error  exception  is  propagated 
outside  the  system  environment  via 
IN  IT_ST  ATE.po  wer_on . 

The  followmg  subfunctions  in  the  BUS  object 
receivmg  raw  bus  data 
cyclic  has  data  output 
raising  bus  error  excepuon 

can  be  reused  in  other  avionic  subsystems.  Therefore  it 
is  sensible  lo  define  a  BUS.CLASS  object,  which  can 
be  instantiated  by  passing  constant  parameters  for  the 
bus  protocol  (minor  cycles,  message  size.s.  memory 
addresses,  etc.).  In  the  level  2  design  stage  the  BUS 
object  is  expected  to  include  an  instance  object  of 
BUS.CLASS. 

Finally  with  the  Formalisation  of  the  Solution  Strategy 
the  ODS  of  the  identified  objects  are  filled  in.  The 
OBCS  of  the  BUS  object  could  look  like  as  follows: 


accept  INTT  do 

call  iniemal  opnatkm 
loop  select  accqn  GET_BUS_DATA 
(BUS_DAT  A:BUS_DATA_TYra)  do 
-  call  GET_BUS_DATA  OPCS 
endGET_BUS_DATA; 
or 

accept  t®T_OUTPUT_DATA{ 
OUTPUT_DATA:  OUTPUT_DATA_TYPE)  do 
--  call  DET_OUTPUT_DATA  OPCS 
end  DET_OUTPUT_DATA; 
or 

delay  0.02; 

if  the  stop  flag  was  set  exit  the  loop; 
if  a  bus  error  was  detected  raise  exception 
call  internal  bus  output  trigger  operation 
end  select; 
end  loop  ; 
end  INTT; 

The  justification  of  the  design  decisions  concludes  the 
first  Basic  Design  Step.  For  each  identified  child  object 
a  further  BDS  is  tun. 

The  refinement  process  is  carried  on  till  the  internal 
object  structure  needs  no  fiiither  decomposition  and  the 
identified  operations  consist  of  simple  sequential  flows, 
which  can  be  easily  implemented  in  ADA  or 
pseudocode. 

After  the  design  has  been  converted  into  Ada  code  by 
the  codegenerator,  die  programmer  completes  the 
source  code  by  adding  for  instance  representation 
clauses,  task  priorities  and  by  substituting  pseudocode 
fragments  with  Ada  code. 

5.  EXPERIENCES 

5.1  HOOD  ADVANTAGES 

The  advantages  of  HOOD,  in  accordance  with  the 
intention  of  its  developers,  are  certainly  to  be  found  in 
the  support  of  the  design  of  large  Ada  systems, 
especially  when  development  teams  are  located  at 
different  sites  and  main  system  components  have  to  be 
subcontracted. 

The  well  defined  process  steps  and  the  contemporary 
production  of  a  d^gn  document,  which  is  structured  as 
the  development  cycle  itself,  enhance  standardisation, 
support  information  exchwge  and  insure  a  transparent 
design  process.  The  automatic  conversion  of  the  HOOD 
design  into  an  executable  Ada  program  alleviates  the 


developer's  work  and  reduces  the  skill  discrepancy 
between  experienced  and  less  experienced  personnel, 
which  has  ofien  a  negative  impact  on  team  synergy  and 
product's  consistency  in  large  development  efforts. 

The  use  of  HOOD  requires  that  the  programmer  only 
needs  to  program  in  the  small;  module  and  process 
structures  are  derived  directly  flom  the  HOOD  design. 
The  strict  lop  down  process  of  HOOD  is  a  powerflil 
feature  for  padually  reducing  system  complexity  by 
decomposition  and  partitioning  into  separaie  work 
packages. 

On  each  system  abstraction  level  the  decomposition 
process  leads  to  a  refuied  object  strucnrie,  however  this 
is  achieved  Ihrou^  a  kind  of  functional  mechanism 
such  as  die  'Implemented-by  link*.  This  can  help  to 
overcome  the  between  SW  specificaiion  arid  object 
oriented  design,  if  a  complete  functional  specification  is 
available  as  input  for  the  design  phase. 

HOOD  enables  the  easy  construction  of  an  executable 
system  model  on  each  abstraction  level  and  supports 
herewidi  early  prototyping. 

The  hierarchical  system  model  supports  two 
complementary  test  strategies  during  SW  Integration: 
Top  down  test  using  SW  snibs 
bottom  up  test  starting  Grom  tested  terminal 
objects. 

5J  PROBLEM  AREAS 

5J.I  SW  REQUIREMENTS  /  OOD  TRANSITION 

Converting  a  pure  functional  SW  specification  into  an 
object  oriented  design  is  a  fundamental  problem.  If  the 
SW  qreciflcation  was  produced  following  a 
conventkxial  function  and  data  model,  some  additional 
problems  will  arise: 

the  flat  structure  of  the  specification  model  is  to  be 
converted  into  a  hieratchical  one 
data  and  functions  have  drifted  apart 
system's  states  and  dynamic  behaviour  are  not 
easy  to  identify  in  the  SW  specification  model. 

We  feel  that  a  restructuring  of  the  SW  requirements  by 
means  of  hierarchical  DFD's  and  STD's  Iik  provided  a 
suitable  basis  for  the  HOOD  design.  The  Dro's  were 
able  to  achieve  the  necessary  abstractions,  to  bring  data 
and  functions  together  and  could  be  easily  derived  from 
the  specification  model,  because  of  simiku'  graphics  and 
semantics. 
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Deriving  STD's  was  more  difficult,  because  although 
the  specification  model  could  express  process 
sequencing,  it  highlighted  relevant  moding  infonnatiun 
insufficiently.  Even  though  the  original  functional 
specifkation  could  be  successfully  convened  into  a  well 
structured  object  oriented  design,  some  disadvantages 
for  requirements  traceability  had  to  be  accepted. 

After  the  design  was  completed,  about  20%  of  the  SW 
requirements  could  not  be  clearly  related  to  a  design 
object;  they  were  marked  as  "panly  fullfiHed*  in  several 
affected  ODS's. 

5.2.2  REAL-TIME  ASPECTS 

If  we  consider  that  HOOD  was  intended  to  suppon 
ADA  and  that  ADA  addresses  embedded  systems,  the 
insufficient  real-time  semantic  must  be  regarded  as  a 
major  problem  with  HOOD. 

We  believe  that  HOOD  diagrams  and  ODS's  do  not 
express  sufficient  system  behaviour  and  miss 
particularly  a  representation  of  operation  call  chains 
together  with  their  activating  events.  Structured-charts- 
like  diagrams  could  be  a  suitable  tool  for  representing 
operation  call  chains  and  convey  additional  control  flow 
information  for  storage  in  the  tool  database. 

HOOD'S  support  for  identification  of  processes  in  the 
system  is.  in  our  opinion,  also  insufficient,  because 
clear  guidelines  for  the  usage  of  the  concepts 
functional  constrained  operation 
constrained  operation  by  type  of  execution  request 
active  and  passive  objects 
are  missing  in  the  Reference  Manual. 

Little  support  was  found  for  dead-lock  analysis  and 
estimation  of  response  time. 

S.2J  CODE  PRODUCnON 

Mapping  the  design  into  Ada  code  is  in  our  opinion 
another  problem  area  of  HOOD.  The  code  generation 
does  not  produce  any  additional  execution  overhead,  but 
destroys  the  hierarchical  design  structure. 

The  terminal  and  non-terminal  design  objects  appear  in 
the  code  as  a  flat  landscape  of  withed  Ada  pack^es. 
which  cannot  be  clearly  mapped  back  into  the  original 
hierarchy.  The  position  of  the  'with-clause'  before  the 
specification  or  the  body  of  the  Ada  package  was.  in  the 
HOOD  version  3.0,  no  longer  a  clear  hint  for 
distinguishing  a  'use'  and  an  'include'  relationship.  The 
gap  between  design  and  code  structure  obstructs  reverse 
engineering  processes. 


In  addition,  the  HOOD  semantic  does  not  exploit  some 
useful  featiues  of  the  Ada  language,  for  instance  task 
types,  entry  families,  nested  constructs  and  access  types 
(even  though  the  latter  are  no  desirable  features  for  safe 
critical  systems). 

The  structural  gap  between  design  and  code  and  manual 
extensions  of  the  generated  code  produce  negative 
impacts  on  SW  test  and  maintenance.  Copying  manual 
code  extensions  back  into  the  ODS  for  consistency  was 
felt  U)  be  a  duplicated  action.  Maintaining  consistency 
among  several  versions  of  code  files  and  ODS's  was 
sometimes  a  tedious  and  error  prone  process. 

«.  RECOMMENDA'nONS 

Recommendations  will  be  addressed  in  two  directions, 
to  the 

-  HOOD  Users 

HOOD  Technical  Group,  which  is  responsible  for 
the  method  defmition  and  enhancements 

HOOD  UsCTs: 

Recommendations  addressed  to  the  HOOD  user  are: 
lake  real  world  objects  as  a  basis  for  SW 
qiecification,  avoid  separation  of  functions  and 
dm  Objects  must  encapsulate  functions  and  data, 
if  both  are  separated  in  the  SW  specification  the 
identification  of  the  objects  will  be  very  difficult. 
Proceed  iterative  for  SW  requirements  analysis 
and  architectural  design, 
make  use  of  prototyping  in  early  phases  u> 
investigate  dynamic  system  behaviour. 

In  our  days  most  of  the  Project  models  used  for  SW- 
Development  are  based  on  the  'waterfall  model’,  where 
the  SW-design  can  only  be  initiated  after  the  SW- 
specificatkm  has  been  completed  and  accepted.  There 
are  many  reasons  for  this  approach,  because  system  and 
software  knowlegde  for  such  complex  system  may 
reside  in  different  specialists  teams  located  on  different 
sites.  Nevertheless  we  believe  that  a  top  down  iterative 
development  process  (spiral  model)  for  SW 
requirements  analysis  and  SW  design  would  improve 
the  development  process. 

The  use  of  (rapid)  prototyping  in  early  phases  of  the 
project  as  supported  by  H(X)D  will  ensure,  that  the 
dynamic  behaviour  of  the  system  will  be  ui  accordance 
with  the  requirements. 

fdl  in  Object  Definition  Skeletons  (ODS)  with  Ada 
code  as  far  as  possible. 
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This  will  ensure  that  the  SW  design  and  the  Ada  code 
will  be  more  consistent  and  maintainable  and  will 
support  requirements  traceability. 


HOOD  Technical  Group: 

Based  on  our  experiences  the  following  HCX)D 
enhancements  would  be  desirable: 

In  order  to  enhance  the  real-time  capabilities,  we 
would  suggest  extending  the  HOOD  semantic  with 
a  graphical  representation  for  operation  call 
chains.  The  coittrol  information  should  be 
stored  in  the  database  and  could  also  be  used  to 


si^>port  the  identification  of  circular  dead-locks. 

A  processing  time  analysis  mechanism  for  object 
operation  could  be  utilised  for  supporting  an  early 
atutlysis  of  the  system  reactions,  particularly  in 
conjunction  with  prototyping. 

A  mapping  of  the  inclu^  relationship  into  nested 
Ada  packages  could  be,  in  our  opinion,  an 
interesting  approach  to  overcome  the  smictural 
gap  between  SW  design  and  Ada  code  for  shallow 
system  architectures. 

These  real-time  enhancements  would  also  contribute  to 
the  architectural  design,  for  instance,  by  supporting  the 
identification  of  additional  required  synchronisation 
objects  and  the  active/passive  properties  of  the  objects. 


7.  CONCLUSIONS 


The  HOOD  Version  3.0  has  some  shortcomings  and 
weak  areas,  however  we  recommend  HOOD  as  a  very 
{vomising  method  for  'SW-Design'  in  large  Ada 
projects. 

hood's  well  defined  formalised  steps,  the  automatic 
conversion  of  the  design  into  Ada  code  and  the 
automatic  production  of  design  documentation 
improves  tiK  productivity  during  development, 
enhances  information  exchange  and  re-useability 
significantly. 
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OBJECT  Object  Name  IS  [CLASS]  Object  Type 
DESCRIPTION 

IMPLEMENTATION  OR  SYNCHRONISATION  CONSTRAINTS 

PROVIDED  INTERFACE 

(Types,  Constants,  Operations,  Exceptions,...) 

REQUIRED  INTERFACE 

(Objects,  Types,  Operations,  Exceptions,...) 

DATAFLOWS 

OBJECT  CONTROL  STRUCTURE 

(Description,  Constrained  Operations,  Code  or  tmpiemented-by) 

INTERNALS 

(Objects,  Declarations,  Operations) 

OPERATION  CONTROL  STRUCTURE 

(Name,  Used  Operations,  Exceptions,  Code,  Exception  Handlers 
or  Impiemented-by) 

END-OBJECT  Object  Name 

Fig.  3-3  Object  Description  Skeleton 


Fig.  4-1  Context  Diagram 


Fig.  4-2  Data  Flow  Diagram  laval  1 


START 


Fig.  4-5  Obi«ct  Candidates 


Discussion  * 

Questioo  H.  LE  DOEUFF 

What  was  the  real  time  structure  used?  Was  the  conespondeoce  of  one  active  object  =  one  Ada  task  respected?  What 

were  the  teal  tune  peifonnanoes?  * 

Reidy 

The  teal  time  siniclure  has  used  several  Ada  tasks,  defined  as  ’active  objects”.  There  were  no  problems  with  the 
recognized  "real  time”  performance. 
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ABSTRACT 

The  HERMES  On-board  Software  is  executed  in  a  complex  muhi-pnxessor  etivironrnem  composed  of  two 
segregated  computers  pools.  It  provides  all  services  to  control  the  liajectoty  and  the  attiuide  of  the  spaceplane  and 
its  conSguratioa.  It  also  provides  aids  to  the  On-board  Crew  and  the  Ground  Facilities  in  the  Mission  and  Space 
Vehicle  manaBemeiu. 

Being  highly  “Safety  Critical”,  the  control  functions  ate  foreseen  to  be  supported  by  a  quad-computers 

pool  in  hot  redundancy,  tunning  in  parallel  and  tightly  synchronized. 

To  support  “Missioo  Critical"  functions,  as  mission  and  vehicle  management,  a  dual-computers  poo)  in  cold 
redundancy  is  the  baseline. 

This  paper  describes  how  the  um  of  HOOD  methodology  has  been  experienced  in  the  HERMES  On-board 
Software  Mock-Up  framework,  from  now  onwards  designated  for  the  sake  of  brevity  as  MU. 

In  this  uviinirgi  survey  of  MU,  a  number  of  6gures  characterizing  application  size,  specification  and  design 
complexity  of  the  developed  software  along  with  a  technical  balance  of  tte  experienced  methods  are  given. 


Keywords:  Software.  Guidance-Navigation  and  Control,  Design  Methods,  HOOD,  SADT,  Metrics 


1.  INTRODUCTION 

1.1  HERMES  Spaceplane  In-FUgfat  Mission 

The  HERMES  Spaceplane  is  part  of  the  European 
program  to  support  “mn  in  space”  activities.  It  aims  to 
be  a  transfer  vehicle  for  servicing  ^pace  stations  (e.g. 
COLUMBUS)  with  human  operators. 

According  to  this  general  ^jective,  the  “in-flight” 
mission  of  the  spaceplane  may  be  defined  with  three 
main  phases: 

-  the  “launch”  phase,  where  HERMES  acts  as  the 
“equipment  bay”  of  the  ARIANE  S  buncha  in 
order  to  control  the  launch  On^Kxy; 

•  the  “orbital”  phase,  afler  ARIANE  5  jettisoning, 
where  HERMES  is  like  a  “satellite”  and  has  to 
perform  and  orbital  control  as  well  as 

rendez-vous  operations; 

-  the  “re-entry”  phase,  afierdesorbitation  orbital  arc, 
where  HERMES  bectxnes  and  hypersonic  glider. 

1.2  Data  Processing  Organization 

In  order  to  support  the  d)ove  described  fimctions,  the 
Spaceplane  is  designed  lo  around  a  centralized  Data 
Processing  system.  Datt  Processing  system  is 
organized  in  two  segregated  computers  pools  as  shown 
in  Figure  1: 


-  the  GNC  pool  supports  all  “safety  critical” 
fmcUons  of  the  spaceplane  mainly  related  to  flight 
control; 
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-  the  MMC  pool  executes  “mission  critical” 
functions  of  the  iqiaceplane  as;  mission  plan 
execution  and  monitoring  of  the  vehicle 
consuim  resources,  but  is  never  involved  in 
safety  operations. 

The  Mission  pool  is  composed  of  two  computers, 
which  can  manage  the  spacepbuie  subsystems  (Power 
supply  and  distribution.  Thermal  control.  Life  support) 
through  two  cross-strapped  numeric  buses  using 
standard  interface  boxes,  as  shown  in  figure  2.  One 
computer  is  active  and  controls  the  subsystems,  the 
other  one  i^ys  a  monitoring  role  during  the  critical 
phases  of  the  flight  (launch  and  re-entry)  and  may 
supersede  the  first  one  in  case  of  failure.  All  accesses  10 
physical  items  inside  the  subsystems  are  redundant  as 
well  as  numeric  buses  control. 


As  depicted  in  figure  3,  the  GNC  pool  is  composed  of 
four  computers  interconnected  via  a  specific  Inta 
Processor  Network  (IPN).  Each  computer  controls  its 
own  numeric  bus  to  access  navigation  sensors  and 
flight  control  actuators:  ARIANE  5  equipment  for 
launch,  AOC  System  on  orbit  and  Flight  Control 
System  for  atmospheric  re-entry.  During  the  critical 
phases  of  the  flight,  the  four  computers  are  running  in 
parallel  the  same  software,  they  exchange  the  inputs 
data  and  commands  via  the  IPN  to  mutually  monitor 
the  health  of  each  other.  The  GNCs  computen  are 
synchronized  thanks  to  a  specific  protocol  on  IPN. 


1.3  HERMES  On-Board  Software  Functions 


The  functions  supported  by  the  On  Board  Software  are 
the  ftdlowing: 

-  to  acquire  and  execute  the  mission  plan  in  close 


cooperation  with  crew  and  ground.  The  mission 
plan  is  organized  in  “sequences  of  operations”  to 
perform  with  regard  to  pr^fined  events; 

-  to  control  and  monitor  the  execution  of  “sequmces 
of  operations”  defined  in  the  mission  plan,  while 
insuring  a  safe  stattis  of  the  qiaceplanc  and 
monitoring  the  levels  of  consumable. 

The  “operations”  generally  correspood  to  set  the 
subeyst^  in  a  given  configuration,  then  to 
perform  miiaioo-dependem  operations  (Pay-loads, 
Extra  Vehicle  operations)  with  associated  flight 
control  objectives: 

-  to  perform  the  flight  control  operations  according  to 
the  different  flight  phases  and  associated  control 
means; 

ARIANE  5  actuators  for  the  bumch  phase; 
Attitude  and  Orbit  control  thrusters  for  the 
orbital  phase,  rendez-vous  operations  aitd 
desorbitation  arc; 

cold  gas  thrusters  for  the  ending  phase  of 
roidez-vous  (in  proximity  of  the  target); 
flight  control  aero-surfiK:es  for  the 
atmospheric  re-entry; 

breaks  and  nozzle  wheel  during  the  landing 
roU. 

The  mission  poo)  is  in  charge  of  all  “mission 
dependent”  operations  which  arc  not  safety  critical 
The  dual  redundancy  allows  to  cover  one  failure, 
assuming  a  failure  detection  and  recovery  by  the  crew 
(Fail  Operational). 

The  safety  critical  functions  of  flight  control  and 
associated  equipment  management  ate  performed  by 
the  GNC  pool,  which  is  designed  to  be  Ulure  tolerant 
by  implementation  of  FDIR  mechanisms  (Failure 
Detection  Isolation  and  Recovery).  Thanks  to  its  quad 
redundaiKy  and  a  majority  vote  mechanism,  the  GNC 
pool  is  able  to  tolerate  two  failures  (Fail  Safe/Fail 
Operation). 

In  addition,  the  GNC  pool  is  able  to  initiate  and 
perform  autonomously  the  re-entry  operation  in  case  of 
crew  incapacity,  lost  of  ground  communications  or  lost 
of  the  mission  pool. 

For  the  GNC  software,  the  technical  challenge  is 
threefold: 

-  firstly,  to  meet  the  safety  requirements; 

-  secondly,  to  satisfy  a  number  of  very  tightly  real 
lime  constraints  (deadlines)  in  such  a  complex 
(quad,  sytKhronized)  mode; 

lastly,  to  comply  with  processing  power  and 
memory  size  limitations  due  to  space  environment 
(the  software  is  to  be  execut^  by  a  SPARC 
monoprocessor  board  in  each  computer). 

1.4  HERMES  On-Board  Software  Development 
Industrial  Organization 

In  addition  to  the  above  mentioned  technical 
constraints,  the  HERMES  On-Board  Software 
development  has  to  face  with  a  complex  industrial 
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orgmizaltoa  invoiviiig  sevoal  companies  specialized 
in  the  space  software  field: 

•  AEROSPATIALE  as  Prime  coninclor 

•  DASSAULT  AVIAHON  for  Atmospheric  flight 
control  software 

-  MBB  for  Orbital  flight  control  software 

•  MATRA  for  System  software 

-  DATAMAT  for  Mission  management  software 

-  TRASYS  for  Launch  flight  control  software. 

In  Older  to  assess  the  femibility  of  the  HERMES  On- 
Board  Software  development  and  to  experience  the  use 
of  software  design  techniques,  we  start,  three  years 
ago,  a  “Mock-Up”  process  involving  the  main 
participating  companies. 

The  present  paper  gives  a  synthesis  of  the  results  of  this 
process  especially  the  experience  of  using  software 
engineering  methods  and  tools:  SADT,  HCX}D  and  the 
Ada  language. 

2.  MOCK-UP  PROJECT  BOUNDS 

2.1  Purpose  of  the  Mock-Up 

At  the  beginning  of  Cl  phase,  in  1988,  the 
development  and  exploitation  the  MU  was  intended 
to  provide  aids  in  the  verification  of  the  HERMES  On¬ 
board  Software  (HOSW)  specificatKn. 

The  MU  was  m^y  aimed,  on  one  side,  at  providing 
support  for  the  evaluation  of  technical  choices  in  terms 
of:  softwme  architecture;  tradeKiCf  between 
performances  and  functional  requiremeitts:  ADA  Run- 
Tune  needed  features,  and,  on  the  othn’  side,  at 
exercising  the  software  development  methods  and 
ADA  language  to  be  adopted  in  the  HOSW  life  cycle. 

2.2  Organization  of  the  Mock-Up 

The  MU  is  split  in  “Application  SW”  and  “Execution 
Environment”. 

The  “Application  SW”  MU  consists  in  a  number  of 
components  modelling  five  major  functions  of  HOSW, 
namely:  Localisation.  Mission  Management  and  GNC 
for  Launch,  Orbital  and  Re-entry  phases. 

The  MU  “Execution  Environmem”  includes,  as 
software  components,  the  Support  System  Software 
and  the  System  Software  (2nd  Level),  hosted  by  the 
corresponding  MU  “Execution  Environment” 
hardware  components,  that  is,  the  Support  System  and 
the  Core  System. 

In  the  following,  a  brief  overview  of  each  MU 
Application  SW  component  is  given  in  order  to  better 
bormd  the  project  context 

1  LOCAUS  ATION  anoBcation  software  (LOO 
It  simulates  the  localization  function  during  the  orbital 
phase  of  the  Hermes  fliglu,  in  nominal  equipment 
mode.  It  includes  a  system  management  function  of  the 
GNC. 

The  functions  performed  by  the  localisation  software 
are: 


-  calrulatioo:  ensures  the  simulation  of  localisation 
calculations  to  compute  the  absolute  attitude  and  the 
absolute  position; 

-guidance; 

-  acquisuion:  ensures  the  acquisition  of  the  cyclic  data 
generated  by  the  simulated  localisation  equipments 
(IMU.  SST.  GPS)  and  by  the  other  simulated  GNCs 
(for  the  voted  attitude).  It  enables  data  monitoring 
too; 

-  sending:  controls  the  transmission  of  the  generated 
messages  to  the  Support  System  simulating  the 
external  environment; 

-  management:  interprets  and  executes  the  commands 
and  tele-commands  provided  by  the  external 
environment  It  sends  a  cyclic  global  report. 

2.  MISSION  application  software  fMMin 

It  implements  the  following  four  major  functions: 

-  Operations  Plan  Execution 

-  Vehicle  Subsystems  Managernem 

-  System  Configuration  Database  Managernem 

-  Anomalous  cortditions  handling 

The  Operaiiorts  Plan  contains  a  description  of  the 
activities  lo  be  performed  at  run-time:  it  describes  each 
operatkM  in  terms  of  elementary  actions  and 
scheduling  time. 

A  generic  elementary  achoo  is  usually  accomplished 
by  intencting  with  the  components  external  to  the 
MMU  through  the  simulated  ISS3  Bus,  according  to 
specific  communication  protocols. 

The  external  componenu  interfaced  with  the  1SS3  Bus 
are; 

-  Generic  ifehicle  Subsystem  (#1  and  #2); 

-  Operator  Interface  (PPT); 

-GNCL  Mock-Up 

The  transactions  on  the  1SS3  Bus  are  organized  in 
strictly  deterministic  policy:  the  whole  bus  activity  is 
masted  by  one  Bus  Controller  (BC,  the  Mission  MU) 
and  all  other  connected  devices  play  the  role  of  Remote 
Terminals  (RT)  being  polled  by  the  BC.  The  software 
implementation  of  MMU  guarantees  the  correct 
processing  of  all  I/O  transactions  on  the  Bus. 

3.  GNC-Launch  Phase  armljcaiion  software  (GNO.) 

It  reproduces  the  functional  characteristics  of  the 
Ariane  4  Guidance,  Navigation  and  Piloting  functions 
during  launch  phase: 

-  the  acquisition  of  data  from  BGY  and  IMU; 

-  the  navigation,  guidance  and  piloting; 

-  the  launch  flight  sequence  management; 

-  the  telemetry  stream  generation. 

The  execution  of  these  application  components  is 
scheduled  according  to  the  timeband  of  the  component: 
the  timeband  defines  points  regularly  spaced  in  time  at 
which  the  component  must  be  triggered  (triggering 
pmnts). 

4.  GNC-Qrfaital  Phase  application  software  (GSCO) 
The  fuKtional  curabilities  of  the  MU  are  given  in  the 
following: 


•  • 


•  • 
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-  guidance:  the  actual  and  the  desired  otbit  are 
compared.  After  checking  if  both  orbits  intersect  and 
if  both  orbits  lie  in  the  same  orbital  plane.  dilTereni 
strategies  can  be  envisaged. 

•  navigation:  relative  navigation  is  implemoiied.  The 
output  oi  a  simulated  inertial  measutemetu  unit  is 
evaluated.  The  gyro  measurements  (strapdown 
system)  are  integrated.  Quaternions  are  used. 
Acceletomeier  data  are  converted  into  velocities  and 
position  of  the  spaceplane. 

•  Orbital  Flight  Contrtrf:  actual  and  desired  attitude  are 
compared,  the  errors  are  calc  ulated  and  the  desired 
action  is  determined  by  a  phase  plane  controller 
system. 

5.  GNC-Re-enirv  Phase  anolicatinn  software  tCNCRi 
It  implements  the  following  functions: 

-  acquisition  and  processing  of  data  from  GPA  sensors; 

-  guidance  during  hypersonic  and  terminal  flight; 

-  piloting  during  atmospheric  re-entry  phase; 

-  spaceplane  stabilisation  during  atmospheric  re-entry 
phase. 

As  far  as  the  MU  “Execution  Envirotunem**  is 
concerned  the  software  components  are; 

1.  System  Software  (2nd  leveD 

it  provides  the  application  software  MUs  with  the 
services  they  need  ID  properly  run. 

The  offered  services,  from  the  functional  point  of  view, 
are: 

•  scheduling  services 

•  communication  services 

•  time  management  services 

•  monitoring  services 

-  interrupt  handling  services 

2.  Suroort  Sy.’iifflii  Software 

It  provides  software  tools  allowing  the  applicaiion 
software  MU  to  be  experimented,  that  is,  the 
application  software  MU  is  made  free  of  consuming  an 
input  dataflow,  previously  defined  in  a  scenario,  and 
producing  an  output  dataflow,  properly  logged  to  allow 
its  following  analysis. 

As  far  as  the  MU  “Execution  Environment”  is 
concerned  the  hardware  components  are; 

1.  Core  System 

It  represents  the  V3  On-board  Data  Processing 
architecture,  that  is  the  target  machine,  and  mainly 
consists  of  two  Application  Processors  and  a  standard 
VME  bus,  which  links  them  to  each  other  and  to  the 
Support  System  too. 

2-  Simiwi  System 

It  consists  of  one  processor  performing  the  on-line 
functions  in  terms  of  simulated  input  load  to  the  APs 
and,  the  other,  the  on-line  processing  of  oittput  data 
generated  by  the  APs.  Both  the  processors  are 
connected  to  the  VME  bus  of  Core  System. 


3.  MOCK-UP  PROJECT  nCURES 

This  chapter  is  aimed  at  giving  measurements  of  size 
and  complexity  of  the  whole  application  software 
mock-up.  that  is.  LXXT.  MMC,  GNCL.  GNCO  and 
GNCR. 

A  more  user  friendly  mechanism  of  associated  icons  is 
adapted  to  increase  paper  readability  and 
understandability. 

3.1  Size  of  the  Application 

Figure  4  gives,  in  a  synoptic  way.  some  figures  about 
the  size  of  ADA  programs,  constituting  the  LOC, 
MMC  GNCL,  GNCO  and  GNCR  components  of  the 
MU,  and  related  project  documentatkm. 

The  statement  delimiter  (i.e.  “;”)  were  taken  into 
account  in  computing  the  Ada  statements  total  number 


TOTAL  NUM6£A  Of  AOA  SOUACE  STATEMENTS 

ano 

TOTAL  NUMBEfl  Of  COMMENT  l!NE$ 

S400 

total  number  Of  DOCUMENTATION  PAGE  5 

1300 

total  NUMBEROf  AOA  SOURCE  STATEMENTS 
TOTAL  NUMBER  Of  COMMENT  LINES 

4710 

3230 

TOTAL  NUMBEROf  DOCUMENTATION  PAGES 

tfiOO 

-'.£^ 

total  number  Of  AOA  SOURCE  STATEMENTS 

5270 

total  number  Of  COMMENT  l>NES 

ft450 

total  number  Of  documentation  pages 

6S0 

total  NUMBEROf  AOA  SOURCE  STATEMENTS 

3060 

TOTAL  NUMBEROf  COMMENT  lines 

1030 

total  number  Of  DOCUMENTATION  PAGE  S 

SOO 

total  NUMBEROf  ADA  SOURCE  STatcmENIS 

total  number  Of  COAIMENT  LINE  S 

1990 

3900 

total  number  Of  OOCUMENTAriON  PAGES 

<80 

total  NUA«EROf  ADA  SOURCE  STATEMI  n:S 

TOTAL  NUMBEROf  COMMENTliNES 

19000 

total  NUMBEROf  DOCUMENTATION  .'lAGES 

4100 

Figure  4:  Size  of  respectively  LOC.  t4MV.  GNCL, 

GNCO  and  GNCR  components  of  applicaiion 
Mock-Up 


3.2  Metrics  of  Design  Phase  Complexity 

Complexity  does  not  inevitably  mean  lack  of  quality, 
nevertheless  a  complex  design  demands  much  more 
time  for  verification  and  testing.  Generally  speaking, 
the  more  complex  software  design  is,  the  more 
exacting  validating  and  coding  activities  are.  In  the 
following,  every  element,  which  can  be  considered  as 
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iqweaeniaiive  of  design  phase  complexity,  is 
presented. 

3.2.1  Design  Tree  Mcasuremaus 

Figure  S  starts  the  navigatioa  through  the  metrics  of 
design  comidexity  Iqr  providing  the  total  Number  of 
Objects  and  die  Maximum  Depth  values. 


NO;  Number  of  Objects 

It  should  be  considered  only  a  dimensioning  parameier, 
without  any  other  direct  complexity  implication,  since 
both  cases  are  possible:  a  design  with  a  lot  of  very 
trivial  objects  and.  on  the  other  side,  a  design  with  very 
few  objects,  but  extremely  complex. 

MD;  Maximum  Depth 

A  decomposiiian  level  is  added  every  time  that  an 
object,  estimated  not  enough  detailed  needs  to  be 
further  split  into  child  objects. 

The  design  complexity  depends  on  that  value,  which 
only  gives  uiformation  about  the  deepest  branch  of  the 
tree,  without  any  other  indication  about  the  compItM 
arborescence,  being  the  depth  of  other  branches 
unequal 

Generally,  the  higher  Maximum  Depth  value  is,  the 
higher  die  number  of  impkmeiaedjby  optratiOHs  is. 
The  impUmenudJty  relations,  increasing  the  number 
of  links  and  informaiion  conveying,  make  the  design 
more  and  more  unreadable  md  understandable. 

It  is  worth  pointing  out  that,  contrary  to  one  could  think 
and  expect,  the  tiuce  GNC  mock-ups  design  trees 
sensibly  differ 

3.2.2  HOOD  Objects  Metrics 

In  this  section  definition  and  meaning  of  metrics, 
which  were  calciilaied  for  each  HOOD  object 
componing  the  architecuires,  are  given. 

DF:  Dependency  Factor 

The  complexity  of  a  design  increases  depending  on  the 


links  ^aerated  by  the  USE  relation. 

The  Dependency  Factor  takes  into  accoum  the  fact  that 
a  modification  of  an  used  object  can  consequently 
involve  other  modifications  in  tlK  using  objects. 

The  higher  the  DF  value  is,  the  harder  the  management 
of  propagation  of  involved  modifications  is  (waterfall 
modificationsl 

The  Dependency  Factor  of  the  0-,  object  is  calculated 
by  the  summation  of  the  DFs  of  all  the  objects  used  by 
(>,  with  the  convention  of  aibiirarily  setting  to  I  the  DF 
of  objectt  which  do  not  use  any  other  object 

NP;  Number  of  functions  or  Procedures  PROVII^D 
by  an  object 

The  understanding  of  the  interface  offered  by  an  object 
is  mainly  due  to  the  operations  declared  as 
PROVIDED. 

The  intrinsic  complexity  of  an  object  depends  on  the 
number  of  operations  provided  by  both  its  terminal  and 
not  terminal  objects. 

Infact  an  operation  declared  at  several  leveb  as 
IMPLEMEhn^  BY  increases  the  design  complexity, 
even  if  there  will  be  a  unique  procedure  bmly.  at 
termiiul  object  level,  implementing  that  PROVIDED 
operation. 

The  NP  of  the  Oi  object  is  calculated  by  the  summation 
of  the  NPs  of  iu  child  objects  and  where  NP  is  equal  U> 
the  number  of  PROVIDED  operatioiis  for  leraiinal 
objects. 

COG:  COUplii«fKlor 

H(X)D  medndology  recommends  for  designing  an 
object  with  a  number  of  objects  using  it  higher  than  that 
of  used  objects. 

The  Coupling  factor  of  0-,  rightly  expresses  the  ratio 
between  the  number  of  objeca  using  O,  and  that  of 
objectt  used  by  Q,. 

The  mmietaiar  mid  denominalor  of  the  ratio  are 
conventioaally  set  to  1  in  case  of  respectively  no  object 
usiiv  O^  and  no  object  used  by  . 

The  Coqiting  factor  normally  could  be  significantly 
higher  than  I. 

NT;  Number  of  Terminal  objects 
Fually,  the  Number  of  Tbrminal  objects  were 
measured.  If  the  object  0|  is  a  terminal  one,  then  NT  is 
conventionally  set  to  I,  otherwise  NT  is  calculated  as 
the  summation  of  the  Nik  of  the  child  objectt  of  Oi . 

IkUes  1. 2  and  3  summarize  the  HOOD  objects  metrics 
for  each  qgilication  software  mock-up. 

It  could  be  of  some  interest  verifying  that  while  the 
HOOD  theory,  recommending  for  designing  an  object 
with  a  number  of  objects  using  it  higher  than  that  of 
used  objects,  should  lead  to  values  of  coupling  factors 
signific^y  higher  than  I,  on  the  contrary,  the 
applications  show  weak  coupling  factors  values, 
tanging  from  0.12  to,  exceptionally,  10. 
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LOC  and  GNCL  HOOD  bjects  metrics 


3.2.3  Global  Design  Complexity  Measurements 

NT/NO:  ratio  between  the  total  Nonber  of  'Ibrmii  al 
objects  and  the  total  Number  of  Objects 
That  ratio  allows  to  estimate  the  weight  of  global 
decompositioa  and  the  consistency  of  abstraction 
levels  existing  amoi«  pure  logical  objects  and  physical 
objects  which  will  be  given  an  implementing  body. 
The  value  of  NTA40  ratio  is  at  the  most  equal  to  1 ,  as 
shown  by  the  dot  filled  area  in  the  graph  in  figure  6. 
The  smaller  NT/NO  is,  the  mote  HOOD 
decompositioo  owns  abstraction  levete  which  are  not 
justified. 

A  too  functional  decomposition  in  child  objects  does 
not  contribute  to  the  solution  much  more  than  the 
parent  object  does.  A  ratio  too  close  to  1  could  mean 
that  a  too  physical  decomposition  with  a  great  number 
of  terminal  objects  was  carried  out. 

The  overall  trend  in  application  mock-up  designs  is 
that  of  going  directly  and  rapidly  to  the  pt^t,  infoct,  as 
it  can  be  easily  seen,  we  have  something  ranging  from 
0.92  to  0.68,  that  is  we  are  dealing  with  quite  physical 


decomposition,  loo  close  to  the  implementation.  The 
GNCL  and  GNCR,  marking  a  ratio  of  0.92,  have  a 
very-very  physical  decomposition.  It  seems  that  the 
only  concern,  leading  the  architecture  design,  was 
‘‘how  arranging  an  already  fixed  Ada  implementation 
into  HOOD  objects’* 


NP/NT  ratio  between  the  total  Number  of  functions 
or  Procedures  PROVIE^D  and  the  total 
Number  of  Terminal  objects 

NP/NO:  ratio  between  the  total  Number  of  functions 
or  Procedures  PROVIDED  and  the  total 
Number  of  Objects 

Figure  7  allows  us  to  have  a  qukk-look  on  the 
relevance  of  operations  with  regard  to  the  objects. 
While  the  daA  dotted  histograms  show  the  NP/NO 
ratio,  on  the  other  side,  the  light  dotted  ones  give  the 
NP/OT  ratia  It  could  be  useful  recall  now  that  NP 
takes  into  account  the  increasing  of  complexity  of  an 
interface  due  to  the  IMPLEMENTED  BY  mechanism, 
that  is,  NP  is  not  merely  the  summation  of  the 
PROVIDED  interfaces  of  the  overall  design. 


0bf4€t$ 


3.3  Metrics  of  Specification  Phase  Complexity 

This  section  is  aimed  at  providing  some  metrics 
associated  to  the  specification  complexity,  recalling  in 
some  way  those  already  shown  for  the  design 
complexity. 

3.3.1  Model  Structure  Measurements 

Figure  8  provides  the  total  Number  of  boxes  of  the 
SADT  m^i  and  the  Maximum  depth  of  functional 
decomposition. 


7lfnr«  I:  Nmtbtr  of  Botm  omd  Mmmm  DofUk  of  LOC, 


MMU.  GNCL,  CNCOmi^CNCM  SADTmtHUU 


Nb:  Number  of  boxes 

It  should  be  considered  only  a  dimensioning  parameter, 
without  any  other  direct  complexity  implication.  It 
takes  into  accoum  the  diversity  of  all  the  activities 
owned  by  a  model  including  also  those  activities  due  to 
the  abstraction  level  mechanism  (ix.  noo-kaf  boxes). 

Md:  Maximum  depth 

A  decomposition  level  is  added  every  time  that  an 
activity,  estimated  not  enough  specified,  needs  to  be 
further  split  into  child  boxes.  The  problem  statement 
complexity  depends  on  that  value,  which  only  gives 
information  about  the  deepest  branch  of  the  tree, 
without  any  other  indication  about  the  complete 
arborescence,  being  the  depth  of  other  branches 
unequaL 

It  is  worth  pointing  out  that  the  mock-ups  SADT  trees 
substantially  mirror  the  corresponding  design  trees 
structure. 

3.3.2  SADT  Non-Leaf  Boxes  Metrics 

In  this  section  definition  and  meaning  of  metrics, 
which  were  calculated  for  each  non-leaf  box 
componing  the  SADT  model,  are  given. 

W;  Weight 

This  metric  measures  the  diversity  of  the  basic 
activities  included  in  a  non-leaf  box.  The  weight  of  a 
non-leaf  box  is  the  number  of  leaf  boxes  included  in  its 
descendants.  The  weight  of  a  leaf  box  is  conventionally 
set  to  1. 


Cc:  Structural  Complexity  of  communication 
This  metric  measures  the  complexity  of 
communication  between  the  elements  of  the  box 
decomposition.  It  is  calculated  as  the  sum  of  toul 
number  of  connections  between  the  box  children  and 
the  number  of  interface  points  of  child  boxes  attached 
to  their  parenu 

Db:  Dispersion  of  the  breakdown 
It  is  an  indicator  of  the  uniformity  of  the  decomposition 
of  a  non-leaf  module.  It  is  equal  to  the  standard 
deviation  of  the  weights  of  the  child  boxes. 

Cb:  Cohesion  of  the  breakdown 
It  measures  the  density  of  the  links  between  the 
children  of  a  non-leaf  box.  It  is  calculated  as  the  ratio 
between  the  number  of  pairs  of  children,  which  are 
connected  by  at  least  one  channel,  and  the  total  number 
of  possible  pairs  of  connected  children. 

Ci:  Cohesion  of  the  inheritaiKC 
It  measures  the  density  of  the  links  between  a  non-leaf 
box  and  the  elements  of  its  decomposition.  It  is 
calculated  as  the  ratio  between  the  number  of  interfaces 
inherited  by  the  child  boxes  and  the  number  of  child 
boxes  of  the  non-leaf  box. 

Table  4  summarizes  the  SADT  boxes  metrics  for  each 
application  software  mock-up. 
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3.33  Olobd  SpeciflcMion  Complexity  Meaguiemems  4.  MOCK-UP  PKOJECT  TECHNICAL  SURVEY 


W/Nk:  iMio  between  the  Weight  of  the  model  and  the 
total  Number  of  boxes 

That  latio  allows  to  estimate  Ifae  televance  of 
abstiacliao  levels  with  r^atd  to  the  global 

The  value  of  W/Nb  ratio  is  at  the  most  equal  to  1  (only 
one  decompoeitioo  level),  as  shown  by  the  dot  filled 
area  in  the  graph  in  figure  9. 
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Giving  a  feeling  of  experienced  methods,  being 
supported  by  the  cakiilaied  metrics,  without  any 
pretence  to  a  rigorous  approach  or  an  accurate 
evaluation,  is  just  the  main  goal  of  this  synthesis. 

-  As  qualitative  conclusion,  it  seems  that: 

the  problem  specification  was  iqiproached  more 
repil^  and  homogeneously  ttn  the  aointion 
definition  was; 

-  all  the  designs  were  approached  mainly  with  the 
concern  of  fitting  the  HOOD  architecture  into  an 
already  existing  Ada  implemeiMation  as  problem 


•  the  HOOD  hierarchical  abstractioo  mechanism  was 
felt  more  as  an  obstacle,  rather  than  ar  emway 

of  organizing  the  software  implement.,  jott 
Fuially,  it  is  worth  noticing  that  tte  values  of  ratios 


As  it  can  be  easily  seen  there  is  no  significant 
difTerence  in  how  the  problem  statement  was  specified 
using  SADT  methodology. 


....... 


n(«riU: 


eo4t  MU  arf  SADT-HOOD 


Flew*  ire 


MHuoMct  Of  MUM  it^  tmfmd  10  mt  metmMiu 


ratio  bttween  the  total  Number  of  data  and 
the  model  Weight 

Nd/Nb;  ratio  between  the  total  Number  of  data  and 
the  total  Number  of  boxes 

Figure  10  allows  us  to  have  a  quick-look  on  the 
relevance  of  data  with  regard  to  the  activities. 

While  the  dark  dotted  histograms  show  the  Nd/Nb 
ratio,  on  the  other  side,  the  light  doited  ones  give  the 
Nd/W  ratio.  It  could  be  useful  recall  now  that  Nd  is  an 
indicator  of  the  information  quantity  presem  in  the 
model. 


between  the  code  size  of  GNC  application  mock-ups 
are  (giite  similar  to  those  between  the  corresponding 
SAOT-HOOD  dimensioning  parameters  (see  figure 
11). 


5.  CONCLUSION 

The  main  results  we  got  in  the  Mock-Up  expoience  are 
the  following; 

1.  apfdicabilitv  of  methods  for  the  On-Board  software 
dCYClflPmCUt 

The  software  engineering  methods:  SADT,  HOOD 
axl  the  ADA  language  were  successfully  used  in 
the  Mock-Up  development  process. 

It  means  that  these  methods: 


■  ciD  te  used  logethcr  in  the  nme  devfllopineni 
prooett;  SADT  tor  the  requiiemem  phase, 
HOOD  for  the  design  and  Ada  language  for  (he 
coding  phase; 

-  can  be  used  in  a  distributed  envirooment  involv¬ 
ing  several  companies  on  several  get^iaphical 
sites; 

-  generally  improve  the  software  developroent 
productivity  and  quality,  even  if  some  aspects 
are  not  covered  (e.g.  time). 

All  these  evaluation  elements  ate  obviously  only 
qualitative  and  do  not  preclude  the  possibility  of 
using  other  methods.  Anyway,  we  ^  that,  from  a 
management  point  of  view,  such  methods  allow  a 
clear  understanding  and  a  good  visibility  of  the 
software  design  and  thus  a  good  control  of  the  soft¬ 
ware  developmenL 

2.  methods  mastered  bv  the  space  software  industry 
All  the  companies  involved  in  the  HERMES  On- 
Board  software  development  successfully  used 
these  methods.  It  means  that  the  methods  are 
matine  enough  to  be  used  in  an  industrial  develop- 
inent.  it  also  means  that  the  industrials  are  trained 
and  aware  of  the  use  of  these  methods. 

It  is  also  worth  pointing  out  that  the  use  of  common 


methods  allows  a  standardization  and  an  harmoni¬ 
zation  inside  a  software  project,  every  participant 
speaks  with  the  same  language  and  has  the  same 
understanding. 

3.  availabUitv  of  metrics 

TiM  main  pragmatic  result  of  this  study  is  the  avail¬ 
ability  of  statistics  which  allow  to  define  some  met¬ 
rics  or  ratio  linking; 

-  the  complexity  of  the  problem  (according  to 
SADT  metrics) 

-  the  complexity  of  the  design  (HOOD  metrics) 

-  the  size  of  the  SADT  model;  number  of  boxes  aitd 
arrows 

-  the  size  of  the  design:  number  of  objects,  number 
of  operatiorts 

-  the  software  size:  number  of  lines  of  code. 

These  ratio  are  available  for 

-  management  purposes,  as  estinoation  figures  to 
evaluate  with  more  accuracy  the  software 
development  effort; 

-  development  corurol,  to  verify  the  adequation  of 
the  design  effort  to  the  problem  complexity; 

-  quality  assurance,  these  ratio  are  also  very  use¬ 
ful  to  check  if  the  software  complexity  is  glo¬ 
bally  under  control. 


Discussion 


(^stion  C.  KRUEGER 

What  was  your  experience  with  using  H(X)D  in  your  project  relative  to  the  real-time  perfonnartce  of  your  system?  Does 
HOOD  provide  the  features  needed  to  support  teal-dme  performance? 

Reply 

Real-time  performances  should  be  measured  on  the  target  system.  Unfortunately,  our  mock-up  development  was 
designed  to  be  executed  ot  a  "host"  computer.  Real-time  p^onnances  of  HOOD  in  providing  support  for  real-time 
architecture  has  been  pointed  out  through  this  experience. 
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CXMiCEPTIOH  UXSICIELLE  DE  SYSTEME  REACTIF  AVEC  UME  METHODOLOCIE  O' AUTOMATES 

UTILISAMT  LE  LANGA(X  LOS. 


J J .  Bose 

Thoason-CSF,  division  CHI 
40/47,  Quai  le  Gallo 
S2103  -  Boulogne-Billancourt 
France 


inMMfiTffr  : 

La  phase  de  conception  d'un  systAae  rdactif 
est  certaineaent  la  plus  ddllcate,  ne 
serait-ce  que  parce  que  les  choix  qul  seront 
fait  ne  pourront  Atre  confirsiAs  qu'en  phase 
d' intAgratlon  du  logiciel  avec  le  aatAriel. 
Car  e'est  seulement  A  ce  ooaent  lA  que  le 
respect  des  contraintes  tenps  rAel  pourra 
Atre  vArifiA. 

II  faut  done  adopter  une  aAthode  rigoureuse 
prenant  en  coapte  les  spAcificitAs  du  pro- 
blAae  A  rAsoudre,  supportAe  par  un  foraalis- 
■e.  le  langage  LOS.  Jusqu'oCi  peut-on  aller 
avec  ce  langage,  et  quelles  sont  les  techni¬ 
ques  de  codage  assoc lAes  7 

IHTRQDUCTIQN  : 

AprAs  avoir  exposA  les  besoins  d'un  foroa- 
lisoe  pour  la  conception,  qul  ressortent 
aprAs  la  phase  d' analyse  d'un  systAae  rAac- 
tif,  nous  verrons  la  possibilitA  et  les  so¬ 
lutions  proposAes  autour  du  langage  LOS. 

Un  systAne  rAactif  est  caractArisA  par  : 
des  contraintes  tenps  rAel; 

plusieurs  processus  asynchrones  qui  sont  en 
gAnAral  des  aachines  A  Atats; 

un  flot  de  contrOle  iaportant  :  coabinatoire 
iaportante  d' Atats  et  d'AvAneaient  ; 

peu  de  transformation  de  donnAes. 

Ce  type  de  systAae  se  rencontre  frAqueaaent 
dans  le  doaaine  des  applications  de  tAlAcon- 
aunicatlon  par  exeaple. 

Les  spAclfications  logiclel  de  tel  systAae, 
et  de  beaucoup  d' autre,  sont  en  gAnAral  de 
nature  fonctionnelle,  et  rApondent  A  la 
question  :  "que  faut-il  faire  7" 

Mais  la  prApondArance  du  flot  de  contrOle, 
et  les  contraintes  temps  rAel  conduisent  A 
analyser  et  A  spAclfier  Agaleaent  le  compor- 
teaent  dynaaique. 


Ainsi  I'analyse  dAbouche  typiqueaent  sur 
trois  types  de  description  : 

-  description  statique  ou  fonctionnelle  :  qui 
pernet  d'expriaer  que  la  fonction  d'un  sys¬ 
tAne  coaplexe  se  dAcoapose  en  sous- 
fonctions,  qui  elles-nAnes  peuvent  Atre  dA- 
coaposAes  et  ce  jusqu'A  identifier  des 
fonctions  AlAaentaires.  Classiqueaent  une 
telle  description  peut  s'appuyer  sur  la  aA- 
thode  SA  (Analyse  StructurAe)  .  Cheque  niveau 
de  dAconposition  peut  Atre  dAcrit  par  un 
diagraaae  de  flot  de  donnAes  qui  prAcise 
quelles  sont  les  informations  AchangAes  par 
les  sous-fonctions  reprAsentAes  par  des  pro¬ 
cessus  de  transforaation  de  donnAes. 

-  Description  du  coaporteaent  :  qui  expriae  la 
naniAre  d'activer  les  processus  de  transfor¬ 
aation.  Chaque  configuration  de  processus 
actifs  siaultanAaent  A  un  instant  donnA, 
reprAsente  un  node  de  functionneaent  du  sys¬ 
tAae.  Chaque  changeaent  de  node  de  fonction- 
neTCCt  et  les  conditions  du  changeaent  peu¬ 
vent  Atre  dAcrits  par  un  diagraaae  de  flot 
de  contrOle . 

-  Description  dynaaique  :  peraet  de  spAcifier 
la  loglque  et  le  sAquenceaent  des  Achanges 
d' informations  entre  processus  siaultanAaent 
actifs,  correspondant  A  un  aode  de  fonction- 
neaent,  et  le  aonde  extArieur. 

Dans  un  aode  de  fonctionneaent  donnA,  tous 
les  processus  actifs  ne  participent  pas  for- 
cAaent  A  un  nAae  type  d'Acheinge.  II  peut 
Atre  intAressant  de  ne  faire  figurer  dans  un 
scAnario  que  les  processus  acteurs.  Ainsi  A 
un  aode  de  fonctionneaent  peuvent  Atre  asso- 
ciA  plusieurs  scAnarios. 

Les  scAnarios  sont  eux-aAs»  raffinables,  et 
peuvent  Atre  dAcoaposAs  en  sous-scAnarios  A 
chaque  niveau  d'abstraction  auquel  corres¬ 
pond  un  diagraaae  de  flot  de  donnAes. 

Ces  scAnarios  peuvent  Atre  dAcrits  graphi- 
queaent  A  partir  de  diagraames  d' Achanges  ou 
les  exigences  temps  rAel  peuvent  Atre  indi - 
quAes,  et  permettent  de  spAclfier  I'ensemble 
des  protocoles  gArAs  par  le  systAae. 


Presented  at  an  AGARD  Meeting  on  Aerospace  Software  Er^ineering  for  Advanced  Systems  Architectures',  May  1993. 


Les  perforaances  teaps  r6el  de  la  conception 
sont  eaaentielleaent  llAes  aux  parall^lisae 
des  processus.  II  est  done  iaportant  d' iden¬ 
tifier  trds  tot  le  parallOlisae.  peraettant 
de  dOgager  des  processus  coaaninicants  qui 
seront  autant  de  aachines  k  Otats. 

Il  est  tentant  d'adopter  une  dOaarche  orien- 
tOe  objet  pour  des  raisons  Ovidentes  de 
aaintenabilitO .  de  r^utilisabilitO,  ... 

Mais  14  encore  la  prise  en  coapte  du  flot  de 
contrOle,  et  le  respect  des  trois  analyses 
fonctionnelle  aais  surtout  coaporteaentale 
et  dynaaique,  conduit  4  s'intOresser  d'abord 
aux  OvOneaents  4  traiter. 

Les  deux  approches  ne  sont  d'ailleurs  pas 
incoapatibles  :  ”Un  objet  a  un  4tat,  un 

coaporteaent  et  une  identitO”  (G.  BOOCH) .  La 
notion  d'Otat  est  le  critOre  nuaOro  un  pour 
identifier  les  objets  actifs,  qui  devront 
traiter  I'enseable  des  OvOneaents  en  prove¬ 
nance  du  aonde  extOrieur.  et  qui  devront  rO- 
agir  par  rapport  eux. 

Le  preaier  niveau  de  I'analyse  fonctionnelle 
identifie  un  certain  noabre  de  processus 
traitant  des  inforauitions  en  provenance  di- 
recte  du  aonde  extOrieur.  C'est  I'environne- 
aent  qui  iapose  le  parallOlisae  nOcessaire 
de  I'application,  ainsi  les  processus  figu¬ 
rant  4  ce  niveau  fournissent  les  grand  axes 
du  parallOlisae  4  identifier. 

En  se  laissant  orienter  par  le  flot  de  con- 
trOle,  les  fonctions  identifiOes  dans  chacun 
des  diagraaaes  de  flot  de  donnOes  doivent 
Otre  regroupOes  de  aaniOre  4  autoriser  la 
simultanOitO  des  scenarios  dOfinls  dans  cha¬ 
cun  des  aodes  de  fonctionneaent  de  I'appli¬ 
cation.  Ces  regroupeaents  peraettent  d' iden¬ 
tifier  les  objets  actifs  reprOsentant  le 
parallOlisae  stricteswnt  nOcessaire. 

Un  certain  noabre  de  conflits  peuvent  appa- 
raltre  4  1' occasion  de  ces  regroupeaents 
lids  4  I'accds  aux  donndes  partagdes  rdaa- 
nentes.  Afin  d'dviter  I'apparition  de  don- 
ndes  globales,  toujours  dtmgereuses  dans  les 
systdaes  aultitdehes  aonoprocesseur .  I'en- 
capsulation  est  souhaitable. 

L'encapsulation  peraettant  de  aettre  en  pla¬ 
ce  I'exclusion  autuelle  peut  conduire  4  fai- 
re  apparattre  de  nouveaux  processus.  L'en- 
seable  des  processus  pourront  acedder  aux 
donndes  rdaanentes  par  aessagerie  avec  ces 
processus  nouvelleaent  identifids,  ce  qui 
ndanaoins  peut  dtre  coQteuxen  teaps. 

Le  foraalisae  ndcessalre  durant  toute  cette 


ddaarche  critique  d'analyse  doit  rdpondre 
aux  besoins  suivants  : 

-  approche  hidrarchique  structurde  peraet¬ 
tant  de  jalonner  les  diffdrentes  dtapes  de 
regroupeaent .  conduisant  aux  objets  actifs. 

-  La  Bodularitd  identifications  des  objets 
actifs  qui  encapsulent  les  donndes,  et  de 
leurs  interfaces. 

-  Concepts  de  base  du  teaps  rdel  :  paralldlis- 
ae,  coaaunication,  gestion  du  teaps.  . . . 

-  L'expression  du  coaporteaent  des  objets  ac¬ 
tifs  sous  forae  de  aachines  4  dtats. 

L'utilisation  sans  prdcaution  de  la  prograa- 
aation  structurde  pour  expriaer  le  coaporte¬ 
aent  conduit  dans  bien  des  cas  4  une  aauvai- 
se  lisibilitd  et  aaintenabilitd  du  logiciel. 
Les  raisons  principales  sont  les  suivantes  : 

-  les  traiteaents  du  flot  de  contrOle  et  du 
flot  de  donndes  sont  adlangds,  et  il  est 
trds  difficile  de  distinguer  les  variables 
d'dtats  et  les  dvdneaents  des  donndes. 

-  Un  grand  noabre  de  variables  d'dtat  de  type 
staple,  exeaple  un  boolden,  tout  au  long  du 
prograne  provoque  frdqueaaent  un  noabre  ia¬ 
portant  de  tests  de  ces  variables,  afin  de 
ddterainer  I'action  4  produire.  Ceci  a  pour 
effet  d'obtenir  trds  vite  localeaent  un  noa- 
bre  d' iabrications  inacceptable,  ou  d'engen- 
drer  des  tests  coaplexes  et  aultiples.  ce 
qui  dans  les  deux  cas  nuit  4  la  lisibilitd. 

-  La  structure  de  contrOle.  qui  devrait  avoir 
en  charge  la  aise  4  jour  des  variables  d'd¬ 
tat,  ne  peut  pas  dtre  facileaent  Isolde.  De 
ce  fait  elle  se  retrouve  dilude  dans  I'ap¬ 
plication,  et  variables  d'dtat  et  dvdneaents 
sont  consultds  et  aodifids  de  partout  (va¬ 
riables  globales)  .  ce  qui  dans  un  contexts 
aultitdche  est  particulidreaent  dangereux. 

-  Lorsque  les  dtats  n'ont  pas  dtd  claireaent 
identifids  au  prdalable,  le  risque  est  grand 
de  voir  apparattre  des  variables  d'dtat  au 
fur  et  4  aesure  de  I'dlaboration  de  la  con¬ 
ception  ddtaillde.  Le  foisonneaent  des  va¬ 
riables  d'dtat  a  pour  consdquence  de  coa- 
plexifier  inutileaent  le  contexte  ce  qui 
rend  le  logiciel  diff icileaent  testable. 

L'analyse  du  coaporteaent  devient  ddlicate, 
la  description  peut  diff icileaent  dtre  ex¬ 
haustive,  la  prise  en  coapte  de  nouveaux 
dtats  peut  entrainer  des  effets  de  bords  et 
des  rdgressions. 

11  faut  done  se  soucier  en  phase  de  concep¬ 
tion  de  llaiter  le  noabre  de  variables  d'd¬ 
tats  en  les  regroupant. 

On  peut  reaplacer  n  variables  binaires  par 
une  seule  variable  pouvant  avoir  2"  valeurs 


t 
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«u  plus,  car  psral  toutes  cea  valeurs  toutea 
ne  sont  pas  torcAaent  pertinentes. 

II  est  en  g^in^ral  plus  staple  cMs  la  concep¬ 
tion  d' Identifier  la  liste  des  "gtats*  pos¬ 
sibles  pour  chacun  des  processus. 

11  vient  ainsi  plus  naturelleaent  de  posi- 
tionner  une  seule  variable  pour  g^rer  chacu- 
ne  de  cea  listes. 

u  umoAflE  u?a  : 

Un  foraalisae  ripond  aux  besoins  exposes  ci- 
dessus,  et  a  6tg  spgcialeaent  d^fini  pour 
I'analyse  et  la  description  des  applications 
de  t61bcoaaunication  par  le  CCITT  (recoaasLn- 
dations  Z.lOO)  :  le  langage  SOL  (Specifica¬ 
tion  and  Description  Language,  LOS  en  fran- 
pais) . 

Ce  langage  propose  une  double  syntaxe,  gra- 
phique  et  textuelle.  ce  qui  fournit  une  bon¬ 
ne  lisibillte  du  aodble  et  permet  la  verifi¬ 
cation,  la  siBulation  et  la  generation  de 
code. 

II  existe  trots  types  de  description  en  LDS 
correspondent  k  trots  etapes  de  conception  : 


-  descnplK)ii  hicrarchiquc 


. f 

-  deacnpiion  des  moyens 

de  eomniunication  ^ 


-  descnptKMi  du  componemeni 


Un  'processus*  represents  une  aachine  k 
etat,  qui  peut  etre  dgcrite  par  un  autoaate 
unique  ou  constitue  de  plusieurs  autoaates  : 
les  'services*.  Les  'processus*  ou  'servi 
ce*  peuvent  faire  appel  k  des  sous-autosMtes 
appeies  'procedures* . 

A  cheque  noeud  de  I'arbre  on  peut  associer 
des  declarations  textuelles  (declaration  de 
type,  de  'signaux* . . . . ) .  Les  variables  ne 
peuvent  etre  dedarees  que  sous  un  'proces¬ 
sus*. 

A  cheque  niveau  ('bloc”,  “processus*,  servi¬ 
ce*)  les  entites  identifibes  dans  la  vue 
hterarchique  peuvent  etre  “reliees*  entre- 
elles  par  des  “channels”  ou  des  "routes*. 
Cheque  lien  synthetise  un  sous-protocole ,  et 
identifie  la  liste  des  “signaux*  qui  peuvent 
etre  echangAs 

C'est  le  deuxlAae  type  de  description  qui 
peraet  de  reprAsenter  ces  liaisons. 

Enfin  le  troisiAoe  type  de  description  est 
utilisA  pour  dAcrire  le  coaportemont  des 
"processus*,  des  "services*,  et  des  “procA- 
dures”,  sous  forae  d'autoaates  k  Atats  fi¬ 
nis. 

Si  on  appelle  "Atat"  une  coabinaison  parti - 
culiAre  des  variables  de  I'application  dans 
une  situation  donnAe  et  “AvAnesient"  toute 
inforaation  nouvelle  susceptible  de  aodifier 
le  contexts,  un  autoaate  d'Atats  finis  dA- 
crira  toutes  les  coabinaisons  "Atats/AvAne- 
aents*  possibles. 

L' autoaate  peut  Atre  reprAsentA  sous  forae 
d'une  SKttrice  avec  les  Atats  en  ordonnAe  et 
les  AvAneaents  en  abscisse.  Cheque  couple 
Atat/AvAneaient  reprAsente  une  situation  en- 
visageable. 

Dans  un  Atat  donnA,  1 'occurrence  d'un  AvAne- 
aent  entraine  I'exAcution  d'une  “transi¬ 
tion*.  Collc-ci  consiste  k  effectuer  un  ou 
plusieurs  traiteaents  et  se  teraine  par  up 
changeaent  d'Atat. 


L'architecture  de  I'application  est  dAcrite 
k  I'aide  du  preaier  type  de  description.  La 
racine  de  "I'arbre"  reprAsente  I'enseable  du 
"systAme"  qui  peut  se  dAcoaposer  en  "blocs". 

Cheque  "bloc”  pouvant  A  son  tour  Atre  cons- 
tituA  de  "blocs",  et  ce  autant  de  fois  que 
souhaitA,  ou  en  "processus". 

La  sAaantique  associAe  au  "bloc"  est  assez 
libre.  Un  "bloc"  peut  reprAsenter  une  faail- 
le  de  functions,  une  sous-applicatlon  rAsi- 
dant  sur  un  processeur,  ou  plus  siapleaent 
un  certain  niveau  d' abstract ion.  ? 


^  trwiti— 
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Le  contexte  n'est  pas  forc^aent  repr6sent4 
coaplAteaent  par  "I'^tat".  ll  peut  Atre  uti¬ 
le  de  conserver  des  variables  d'Atat  ddfi- 
nissant  des  Atats  secondaires.  D'autre  part, 
le  rAsultat  d'un  traiteaent  doit  pouvoir  in- 
fluer  sur  I'Atat  sulvant  en  fin  de  transi¬ 
tion.  Ainsi  le  traiteaent  d'un  AvAneaent 
peut  dAclencher  des  conditions  de  transi¬ 
tions  vers  plusieurs  Atats  suivants  possi¬ 
bles. 

Les  avantages  d'une  description  sous  forae 
d' automates  sont  : 

-  La  prise  en  coapte  d'une  coabinatoire  Atats/ 
AvAneaents  iaportante  :  cette  approche  pous- 
se  A  se  poser  dans  chaque  Atat  toute  les 
bonnes  questions,  et  A  prAvoir  Agaleaent  les 
cas  prAsuaAs  "impossibles"  (traiteaents 
d'exception) ,  qui  conduit  A  une  description 
exhaustive . 

-  La  lisibilltA  les  automates  se  dAdulsent 
nafurelleaent  des  protocoles  A  iaplAaenter. 

-  La  tra9abilitA  le  contexte  est  sioiple, 
c'est  I'Atat  de  1' automate,  ce  qui  garantie 
une  bonne  testabilitA  du  logic iel. 

La  limitation  du  code  procAdural  :  rAservA  aux 
traltements  des  donnAes. 


Le  LOS  offre  des  aAcanismes,  spAcifiques  du 
temps  rAel,  accessibles  A  I'intArieur  de 
toute  transition  : 

crAat ion/destruction  d' instance  de  processus: 
communication  entre  objets: 
gestion  du  temps. 

Le  nombre  d' instances  de  processus  peut  ve¬ 
rier  au  cours  du  temps  (crAation/destruc- 
tlon).  Chaque  instance  est  identifiAe  A 
I'aide  de  son  PID  (Processus  IDentifier) . 

Les  communications  entre  objets  sont  de 
trois  types  : 

communications  de  type  asynchrone,  rAservAe 
aux  communications  entre  processus  : 


OUPUT/ INPUT 

02 


Communications  de  type  synchrone  : 

PRIORITY  OUPUT/ INPUT 

(rAservAes  aux  comaamications  entre  services 
d'un  aAme  processus) 

SAVE 

no 

(sauvegarde  des  AvAneaents  externes  que  I'on 
ne  souhaite  pas  traiter  dans  I'Atat  en 
cours. 

-  Appels  procAduraux  ; 


C.K^L 


(appel  d'un  sous-automate) . 

TASK 


(appel  d'une  fonction  dAclarAe  dans  un  type 
abstrait) . 

La  notion  de  temps  en  LDS  intervient  A  tra- 
vers  deux  aAcanisaes  : 

-  activation  d'une  teaporisation  :  sur  AchAan- 
ce  un  AvAneaent  est  produit  dans  la  file  du 
processus . 

-  dAsactlvation  d'une  teaporisation  :  la  tea¬ 
porisation  A  dAsactiver  est  identifiAe  par 
1' AvAneaent  A  produire. 

Le  langage  LDS  propose  de  raisonner  d'emblAe 
en  terae  d' automate,  et  1' analyse  se  trouve 
de  ce  fait  guidAe.  Mais  ce  serait  une  erreur 
de  vouloir  tout  reprAsenter  en  LDS. 

En  effet  le  langage  LDS  traite  de  aaniAre 
iaparfaite  le  problAae  de  reprAsentation  des 
donnAes.  II  n'existe  pas  de  notion  de  poin- 
teur,  et  le  langage  ne  rApond  pas  au  besoin 
de  description  de  structures  de  donnAes  com¬ 
plexes  ce  qui  entraine  une  description  LDS 
qui  ne  correspond  plus  au  code. 

D'autre  part  la  description  manque  de  conci¬ 
sion,  il  faut  done  rAserver  I'utilisation  du 
LDS  pour  des  descriptions  "macroscoplques" 
du  fonctlonnement. 

II  est  Clair  que  le  LDS  est  mal  adaptA  A  la 
description  des  donnAes  et  done  des  traite¬ 
aents  qui  s'appliquent  A  ces  donnAes.  Toutes 
les  tentatives  en  ce  sens  dAbouchent  sur  un 
constat  d'Achec. 


•  • 


Chaque  processus  possAde  une  file  d'entrAe 
de  type  "fifo"  destinAe  A  rAceptionner  les 
AvAneaents  en  provenance  d'autres  processus. 
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11  est  done  trAs  iaportant  de  savoir  s'arr^- 
ter  dana  la  deacription  detail 16e  La  diffi- 
cultt  eat  de  ddteralner  la  front  i6re  ou  la 
lialte  d'utillaation,  d'autant  que  le  LDS 
apparatt  comma  trop  riche  ayntaxiqueiaent 
(110  Bota  c163  dans  la  norae  88)  et  A  la 
fois  trop  pauvre  s^aantiqueaent ,  notaaaenl 
par  rapport  aux  langages  6volu6s  de  prograa- 
aation  tel  C  ou  Ada. 

L'utilisatlon  du  LDS  suppose  qu'au  prdalable 
ces  liaites  et  les  restrictions  d'utilisa- 
tion  soient  claireaent  d^finies  avant  de  di- 
buter  la  phase  de  conception.  Au  ainiaua  ces 
rbgles  doivent  indiquer  que  les  traiteaents 
sont  encapsul6s  dcuis  des  types  abstraits 
(NEWTYPE)  ou  bien  encore  dAcrits  de  aaniAre 
inforaelle  (TASK  'aettre  A  jour  la  table  des 
abonnbs' ) . 

L'utilisatlon  du  LDS  en  conception  suppose 
l'utilisatlon  d'un  exAcutif  teaps  rAel  pour 
implAaenter  les  diffgrentes  notions  propo- 
sAes  par  le  langage. 

Il  est  important  de  dAfinir  au  prdalable  les 
rAgles  d'utilisation  du  LDS  et  les  restric¬ 
tions  syntaxlques  et  sAaantiques  ;  aots  clAs 
autorisAs  et  choix  d' implAaentation.  La  con¬ 
ception  peut  en  effet  Atre  trAs  influencAe 
par  ces  choix. 

Ces  difficultAs  aattrisAes,  les  points  forts 
du  LDS  sont  : 


-  la  description  de  1' architecture  logicielle, 

-  le  travail  en  Aquipe  facilitA, 

•  un  guide  A  1' analyse  et  A  la  rAflexion  lors 
de  la  description  des  autoaates 

DEMAKCHE  DE  CONCEPTIQM  EW  LDS 

Les  diffArentes  Atapes  de  la  conception  prA- 
liainaire  sont  : 

-  dAterainer  les  interfaces  avec  I'extArieur. 

-  Identifier  les  AvAneaents  correspondents.  En 
pratique  un  AvAneaent  par  type  d' information 
AchangAe . 

-  Identifier  les  processus  (objets  actifs) . 

-  Description  de  I'architecture  de  I'applica- 
tion  A  I'aide  des  "blocs"  et  des  processus. 

-  DAterainer  pour  chaque  processus  1' interface 
constltuAe  de  I'enseable  des  AvAneaents 
("signal"  en  LDS)  entrant  dans  le  processus. 

-  Identifier  les  ressources  aanipulAes  par 
chaque  processus . 

-  Identifier  les  modes  de  fonctionneaent 
(Atats)  pour  chaque  processus. 


Les  traiteaents  des  donnAes  peuvent  etre 
abordAs  hors  LDS,  en  utilisant  les  types 
abstraits  qui  peraettent  1' abstract  ion  des 
donnAes. 


interfacer  1553 


I 

I  time_out| 


donn6es  abstraites 


♦) 


«) 


♦ 


•  ^ 


•  • 


11-6 


Alnal  4  cluuiue  processus  peut  4tre  sssociAe 
une  hl4rsrchle  de  types  abstrsits  de  don- 
ndes.  Cheque  type  abstralt  foumit  la  llste 
des  opdrateurs  ou  fonctions  qul  peuvent 
s'appliquer  aux  ressources  rAaanentes  qu'il 
encapsule . 

L'objectif  de  la  conception  dStaillAe  est  de 
dScrire  le  coaporteaent  de  cheque  processus 
conforaSaent  aux  aodes  de  fonctlonneaent 
identifies  dans  la  phase  prdcedente. 

Ici  deux  cas  de  figures  peuvent  se 
presenter  : 

es  aodes  de  fonctioimeaent  sont  peu  noabreux 
(aoins  de  20)  et  ils  correspondent  directe- 
aent  aux  etats  de  I'autoaate.  La  description 
de  I'autoaate  eat  siaple  et  represents  coa- 
pieteisent  le  coaporteaent  du  processus. 

Les  nodes  de  fonctionneaents  sont  coaplexes, 
c'est-A-dire  qu'ils  conduisent  4  une  decoa- 
position  de  chacun  d'entres-eux  en  plusieurs 
etats. 

Si  I'on  souhaite  oiniaiser  le  noabre  de  va¬ 
riables  d'etat,  I'autoaate  correspondent 
peut  tres  vite  devenir  difficile  4  aaitriser 
car  la  coablnatoire  etats/eveneaents  diverge 
rapideaent . 

On  peut  dans  ce  cas  utiliser  la  notion  de 
"service*  du  LDS. 

Cheque  service  peut  etre  associe  4  une  fa- 
aille  d'etats,  ou  4  un  aode  de  fonctionne- 
aent.  Ce  n'est  pas  siapleaent  dans  ce  cas, 
une  decoupe  aodulaire  de  I'autoaate.  en  ef- 
fet  I'etat  du  processus  devlent  alors  la 
coabinaison  de  tous  les  4tats  des  services 
le  constituant.  ce  qui  peraet  de  r4dulre 
sensibleoient  le  noabre  total  d'4tats  4  d4- 
crire. 

Si  I'on  adopte  cette  d4aarche  il  peut  4tre 
utile  de  confier  4  un  des  services  le  rOle 
de  chef  d'orchestre  ou  de  supervision.  Les 
4tats  de  ce  service  synth4tisent  les  diff4- 
rentes  coabinaisons  des  4tats  des  autres 
services,  ils  reprAsentent  des  "super-6tats" 
correspondent  alors  aux  diffdrents  aodes  de 
fonctionneaent  du  processus. 


processua  x 


Lorsqu'un  4v4neaent  externe  au  processus 
doit  4tre  traitg  dans  tous  les  aodes  de 
fonctionneaent,  il  doit  alors  4tre  trait4 
par  le  service  de  supervision,  ce  qui  peraet 
de  f actor iser  les  transitions  assoc i4es. 

Il  peut  4tre  utile  de  confier  au  service  de 
supervision  le  soin  de  rAceptionner  tous  les 
4v4neaent3  externes,  afin  de  trailer  au  plus 
tdt  lea  changeaents  de  aode.  Le  service  de 
supervision  dans  ce  cas  se  charge  de  sous- 
traiter  aux  services  concernAs  les  traite- 
aents  associAs  aux  4v4neaents,  ou  siapleaent 
de  les  prAvenir  d'un  changeaent  de  aode 
(synchronisation  des  autoaates) . 

Ces  coaaunications  entre  services,  internes 
au  processus,  doivent  claireaent  4tre  iden- 
tifi4es. 

Les  diffbrentes  4tapes  de  la  conception  d4- 
taillAe  sont  : 

decomposition  des  processus  en  services  (si 
ndcessaire) : 

repartition  des  eveneaents  externes  par  rap¬ 
port  aux  services; 

-  identification  des  coaaunications,  et  de 
1' interface  de  chaque  service; 

-  identification  des  etats  pour  cheque  servi¬ 
ce; 

-  identification  des  traiteaents  utilises  par 
chaque  service: 

-  description  du  coaporteaent  autoaates  4 
etats  finis: 

-  description  des  traiteaents  :  progranatation 
structures . 


CQDAGE  ET  GENERATION  DE  CODE  . 

Arrive  4  ce  stade,  1' ensemble  du  coaporte- 
aent  du  systeae  est  decrit  de  aaniAre  tres 
complete,  et  la  plupart  des  traiteaents  des 
donnees  sont  identifies. 

Il  est  d6s  lors  tentant  d'utiliser  une  gene¬ 
ration  de  code  automat ique  des  autoaates  4 
partir  de  la  forme  textuelle  du  LOS. 

Le  code  genere  s'appuie  obligatoireaent  sur 
un  noyau  temps  reel ,  et  le  code  executable 
genere  peut  utiliser  directement  les  prial- 
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lives  du  noyau. 

Une  autre  approche  consists  4  generer  des 
tables  interpretables,  correspondent  aux  ma¬ 
trices  etats/eveneaents  dans  lesquelles  est 
indiquee  pour  chaque  couple  etats  /evene¬ 
aents  (ou  transition)  la  liste  des  traite¬ 
aents  4  executer. 


■5^ 


i 


•  « 


•  i 


•  •  4 


•  4 


•  4 
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Cette  solution  pereet  d'isoler  la  structure 
de  contrOle  de  1' application,  qui  devient  un 
interpr^teur  de  tables.  Cette  structure  de 
contrdle  peut  ainsi  Atre  facileaent  optiai- 
s6e  en  encoabreaent  aiaoire  et  en  rapidity. 
II  est  souhaitable  que  1' interprAteur  de  ta¬ 
ble  intbgre  des  fonctions  de  trapage  des  ob- 
jets  IDS  aanipul6a,  qui  seront  trfts  utiles 
en  phase  de  aise  au  point  du  logiciel.  ou 
pour  aettre  en  place  une  politique  de  test 
syst6aat ique .  En  effet  les  inforaations  ain¬ 
si  tracges  sont  relatives  au  aodble  de  con¬ 
ception  et  peraettent  de  verifier  le  coapor- 
tement  de  1' application. 


Cette  structure  de  contrble  joue  le  rOle 
d' interface  d'appel  entre  I'application  et 
le  noyau  teaps  r6el,  ce  qui  assure  une  cer- 
taine  inddpendance  par  rapport  i  ce  dernier. 
Le  g6n6rateur  de  code  et  la  structure  de 
contrOle  sont  done  Atroiteaent  lids  et  doi- 
vent  dtre  ddfinis  siaultan^aent . 


0' autre  part  il  peut  6tre  tr6s  utile  que  le 
g^n^rateur  de  code  fournisse  les  interfaces 
avec  les  traiteaents  de  donn^es  qui  eux  se¬ 
ront  codda  i  I'aide  d'un  langage  de  prograa- 
aation  classique.  La  g6n6ration  des  declara¬ 
tions  et  des  "squelettes”  des  procedures  ou 
fonctions  peut  6tre  envisagee. 

L'avantage  d'une  telle  solution  reside  avant 
tout  dans  I'obtention  d'un  code  conforae  e 
la  conception  de  I'application.  L'experience 
aontre  que  la  aoitie  du  code  total  i  produi- 
re  peut  ainsi  etre  deduit  autoaatiqueaent  i 
partir  de  la  conception. 

L'analyse  d'un  systeae  reactif  debouchant 
sur  trois  descriptions  fonctionnelle ,  coa- 
porteaentale  et  oynaaique.  puis  I'utilisa- 
tion  du  foraalisae  LDS  en  phase  de  concep¬ 
tion  en  respectant  un  certain  noabre  de 
regies,  et  finaleaent  une  generation  de  code 
autoaatique  des  autoaiates,  fournissent  les 
aoyens  de  aettre  en  place  un  processus  de 
production  coherent  de  bout  en  bout. 
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Discussion 


Question  Mr  JANVIER 

Avez-vous  ressenii  le  besoin  de  valider  fonnelleinem  ies  automates  au  niveau  specifications,  avant  de  passer  d  la 

realisation?  • 


Reply 

Ce  besoin  n'a  pas  ete  ressenti  sur  les  projets  actuels  car  ils  sont  de  taiUe  moyenne  et  le  comportement  du  systime  est  bien 
nuutrise  par  les  spedalistes  du  domaine.  Cependant,  les  fonctions  des  systteies  reactifs  de  communication  aJlant  en  $e 
complexifiant,  cette  validation  fonnelle  deviendia  certainement  necess^  dans  I'avenir. 

Question  G.  LADIER 

Cette  methode  £acilite-t-elle  ou  nuit-eUe  a  la  reutilisation? 

Reply 

Au  niveau  conception,  la  modification  d'un  automate  est  d'autant  plus  difficile  que  la  decomposition  en  etats  est 
transformee.  De  ce  pmnt  de  vue,  la  reutilisation  doit  Sire  limitee  d  de  faibles  evolutions. 


•  • 
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Abstract 

This  paper  provides  an  overview  of  the 
Artificial  Intelligence  program  at  Rome 
Laboratory.Thc  three  major  thrusts  of  the 
program  are  described.  The  Knowledge-based 
planning  program  seeks  to  develop  the  next 
generation  of  AI  planning  and  scheduling  tools. 
The  engineering  of  knowledge-based  systems 
focuses  on  the  development  and  demonstration 
of  technology  to  support  large-scale,  real-time 
systems  of  Imowledge-based  components.  The 
knowledge-based  software  assistant  program 
seeks  to  develop  a  new  programming  paradigm 
in  which  the  full  life-cycle  of  software  activities 
are  machine  mediated. 


1.  Introduction 

Rome  Laboratory  (RL),  an  Air  Force 
laboratory,  focuses  on  the  development  of 
Command.  Control,  Communications  and 
Intelligence(C3I)  and  related  technological 
capabilities  for  the  Air  Force.  RL  is  designated 
as  a  Center  of  Excellence  in  Artificial 
Intelligence  based  on  its  extremely  successful 
track  record  of  research  over  the  past  decade. 

The  goal  of  Rome  Lab's  Artificial 
Intelligence(AI)  program  is  to  develop  the 
technology  in  Air  Force  needs  areas  and 
demonstrate  applications  to  C3I  problems.  The 
program's  scope  ranges  from  research  and 
devel(q)ment  extending  the  intelligent  functional 
capabilities  of  AI  technology,  to  generic  tools 
ai^  methods  in  broad  areas  of  interest,  to  the 
use  of  AI  in  application  specific  programs. 
Application  programs  are  address^  by  five 
diHerent  Rome  I^b  Directorates  based  on  their 
separate  mission  responsibilities.  These 
programs  include  applications  in  survivable 
adaptive  planning,  intelligence  indications  and 
warning,  smart  built-in-tests  for  electronic 
components,  tactical  command  and  control, 
communications  network  control,  adaptive 
surveillance  and  conformal  antennas.  The 
technology  base  program  addressing 


component  level  technology  and  generic  tools 
is  described  in  the  remainder  of  this  article. 


2.  The  Technology  Base  Program 

Although  state-of-the-art  AI  is  sufficiently 
mature  for  many  near  term  applications,  there 
are  critical  technology  shortfalls  to  address 
before  the  breadth  of  potential  applications 
envisioned  can  be  realized.  The  technical 
opportunities  for  the  Air  Force  include  a  wide 
variety  of  decision  support  systems  which  are 
overwhelmed  by  information,  response  option 
complexities  and  response  time  requirements. 
With  built-in  intelligence  these  systems  can 
overcome  and  improve  their  performance 
where  it  is  currently  limited  by  conventional 
programming  approaches.  Therefore,  the 
technology  base  program  has  been  structured  to 
address  the  generic  technology  needs  common 
to  these  applications.  These  needs  areas  include 
real-time  AI,  parallelism  in  AI,  distributed  and 
cooperative  problem-solving,  AI  acquisition 
and  development  methodologies,  intelligent 
man-machine  interaction,  explanation  in  expert 
systems,  knowledge  base  maintenance, 
reasoning  with  uncertainty,  knowledge 
engineering  for  large  scale  systems  and 
verification  and  validation  techniques.  To 
provide  additional  focus  technology  is  being 
advanced  in  three  major  thrust  areas. 
Knowledge  based  planning,  knowledge  based 
systems  engineering  and  knowledge  based 
software  assistance. 

2.1  Knowledge  Based  Planning 
The  objective  of  this  program  thrust  is  to 
support  the  rapid,  accurate  and  efficient 
creation  and  modification  of  plans:  sequences 
of  action  and  events  designed  to  achieve  certain 
goal  conditions  or  states  in  various  operational 
environments.  There  have  been  developed  a 
series  of  technology  feasibility  demonstrations 
in  the  domain  of  tactical  mission  planning  that 
have  led  to  operational  prototype  systems.  The 
primary  applications  for  this  technology  range 
from  conventional  robotics  planning  associate 
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with  on-board  satellite  control  to  planning  of 
resource  allocation  in  tactical  or  strategic 
mission  planning,  to  planning  of  a  "trajectory" 
a  piece  of  material  might  take  as  its  path  from 
point  of  manufacture  to  point  of  consumption 
in  logistics.  Planning  approaches  differ  in  the 
degree  to  which  there  is  a  man  in-the-loop  of 
the  planning  process,  the  degree  to  which  the 
plans  are  unique  or  stereotypical,  the  rate  at 
which  changes  occur  in  either  the  environment, 
the  plan  or  the  goal  structure  upon  which  the 
plan  is  based,  as  well  as  in  the  temporal, 
causal,  resource  and  task  complexities  of  the 
plan. 

A  new  initiative  focuses  development  activities 
in  this  thrust  on  the  next  generation  of  generic 
planning,  resource  allocation,  and  sch^uling 
technology  to  achieve  an  order  of  magnitude 
performance  enhancement  over  current 
operational  planning  systems.  The 
transportation  planning  and  scheduling 
requirements  associated  with  force  deployment 
in  direct  suppon  of  world-wide  force  projection 
goals  are  being  addressed.  AI  planning 
techniques  are  being  developed  to  meet  these 
daily  planning  activities  of  operational 
commands.  The  principal  product  will  be  an 
integrated,  well-engineered  and  validated  suite 
of  AI  planning  tools  ready  for  application  to 
this  and  other  operational  planning  domains. 
Opponunides  for  technology  advancement  exist 
in  the  areas  of  opportunistic  reasoning  about 
resource  contention,  planning  in  the  large, 
intelligent  reuse  of  plans,  integration  of  AI 
planning  and  decision  analysis,  real-time 
situated  planning,  plan-based  situation 
assessment  and  distributed  planning.  As  a  joint 
Rome  Lab  and  Defense  Research  Projects 
Agency  (DARPA)  initiative,  Rome  Lab’s 
responsibilities  are  to  identify  and  address 
shortfalls  in  projected  operational  capabilities 
based  upon  current  planning  and  scheduling 
technology,  and  to  pursue  through  feasibility 
demonstration  the  development  of  new 
technology  solutions. 

An  early  success  story  under  this  Initiative  was 
the  Dynamic  Analysis  and  Replanning  Tool 
(DART),  developed  on  site  at  USTRANSCOM 
to  meet  specific  requirements  for  Operation 
Desert  Shield. 

As  U.S.  military  forces  pull  back  and  contract 
to  a  "Fortress  America"  posture,  the  importance 


of  strategic  mobility  will  dramatically  increase, 
since  the  luxury  of  forward  positioning  will  be 
gone.  The  demanding  conditions  surrounding 
Operation  E>esert  Shield/Storm  emphasized  the 
importance  of  timely  crisis  action  planning  in 
dealing  with  rapid,  massive  deployments  of 
force. 

The  goal  of  the  DARPA/Rome  Lab  initiative  is 
to  develop  and  demonstrate  the  next  generation 
of  generic  Artificial  Intelligence  (AI)  planning, 
resource  allocation,  and  scheduling  technology 
focused  on  achieving  significant  performance 
enhancements  over  current  DoD  operational 
planning  systems.  The  principal  product 
stemming  from  this  investment  will  be  an 
operationally  validated  suite  of  integrated 
planning  tools  that  will  address  the  large  scale 
planning,  analysis,  and  replanning  problems 
typified  by  strategic  deployment  planning. 

These  tools  will  help  the  CINC  and  his  ata^f 
evaluate  proposed  courses  of  action.  The 
system  would  allow  the  rapid  application  of 
qualitative  criteria  or  decision  rules  to  a  variety 
of  planning  scenarios,  and  facilitate  rapid 
response  to  unforeseen  changes  in  plan 
assumptions,  outcomes  of  actions,  or  external 
conditions.  The  tools  will  also  aid  in  the 
generation  and  maintenance  of  the  force  and 
deployment  databases. 

The  operational  focus  of  this  initiative  is 
transportation  planning  and  scheduling 
associated  with  force  deployment,  specifically 
deliberate  planning  and  crisis  action  planning 
tasks  at  the  National  Command  Authority,  the 
Joint  Staff,  the  major  Unified  Commands,  and 
the  US  Transportation  Command 
(USTRANSCOM)  and  its  service  components: 
Military  Airlift  Command  (MAC),  Military 
Sealift  Command  (MSC),  and  Military 
Transportation  Management  Command 
(MTMC). 

This  initiative  is  divided  into  three  closely- 
coordinated  tiers  of  activity.  Tier  1  is  the 
generic  technology  development  and 
demonstration  tier  where  shortfalls  in  projected 
operational  capabilities  based  upon  current 
planning  and  scheduling  technology  will  be 
identified  and 
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Figurel.  Distributed  Planning 


addressed.  In  Tier  2,  promising  technology 
solutions  will  be  integrated  into  technology 
feasibility  demonstrations  targeted  at  specific 
parts  of  the  crisis  action  planning  problem.  In 
Tier  3  operational  prototypes  based  on  mature 
components  and  technical  successes  of  Tier  2 
will  be  developed  and  fielded  through 
integration  into  the  ingoing  modernization 
programs  of  specific  user  communities. 

The  interface  between  these  three  tiers  will  be 
bridged  by  a  common  prototyping  environment 
which  will  provide  a  ready  medium  for  two- 
way  flow  of  technology  and  domain 
knowledge  between  the  research,  application, 
and  operational  communities.  This  prototyping 
environment,  including  hardware,  software, 
planning  and  scheduling  tools,  and  domain 
faithful  suites  of  test  data  and  intelligent 
simulations,  will  be  available  to  all  participants 
in  either  tier  on  a  "mix  and  match"  basis.  This 
prototyping  environment  will  not  only  serve  as 
the  initiative  vehicle  for  technology  evaluation 
and  transfer,  but  will  evolve  into  an  architecture 
for  advanced  C4  systems.  Maturing  research 
products  that  have  been  thoroughly  tested  in  the 
environment  will  transition  into  operational 
prototypes.  The  successful  development  of  the 
Dynamic  Analysis  and  Replanning  Tool 
(DART),  in  just  ten  weeks,  was  the  first 
application  for  this  process. 

DART  was  developed  to  solve  the  deployment 
force  resequencing  problem.  Initial  technology 


prototyping  experiments  were  conducted  from 
March  to  August  1990.  Late  in  August, 
USTRANSCOM  requested  Initiative  help  in 
accelerating  the  development  due  to  Desert 
Shield  requirements.  In  10  weeks,  the  DART 
system  was  developed  with  DARPA  funds  and 
Rome  Laboratory  technical  suppon. 

The  system  uses  a  relational  data  base, 
graphical  editing  tools,  and  closely  coupled 
simulation  to  speed  modification  of  TPFDDs 
(Time  Phased  Force  and  Deployment 
Databases)  and  analysis  of  operational  plans. 
DART  resides  on  a  Sun  workstation  and  can 
exchange  data  with  WWMCCS  hosts.  An 
open  system  architecture  was  a  design 
requirement  and  a  large  ponion  of  the  DART 
software  is  commercial  off-the-shelf.  A 
second  phase  is  currently  under  way  to  enhance 
and  productize  DART.  While  DART  provides 
some  plan  handling  and  analysis  capability, 
initial  force  generation  planning  remains  a 
manual,  error-prone  process. 

USTRANSCOM  used  initial  prototypes  to 
make  deployment  decisions  early  on  in  Desert 
Shield.  During  October,  DART  was  used  and 
positively  impacted  analysis  conducted  by 
USTRANSCOM.  The  resulting  deployment 
was  the  largest  ever  in  the  associated  time 
period.  In  November,  DART  was 
demonstrated  to  CINCTRANS  and 
immediately  fielded  to  Europe  to  assist 
CINCEUR  in  deploying  tanks  and  personnel  to 
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Saudi  Arabia.  CINCEUR  planners  were  able 
to  use  DART  after  a  single  day  of  training. 
USTRANSCOM  planners  have  also  used 
DART  as  a  key  tool  for  redeploynvent  planning 
of  troops  and  material  back  from  the  Persian 
Gulf  theater.  DART  has  been  qualitatively 
compared  to  the  JOPES  on  WWMCCS.  The 
system  facilitated  an  order  of  magnitude  speed¬ 
up  of  the  editing  and  analysis  cycle  used  by  the 
Crisis  Action  Team  at  USTRANSCOM.  The 
graphics  in  DART  also  improve  upon  the 
JOPES  interface,  enhancing  the  ability  to 
visualize  plans  and  smoothing  the  learning 
curve  considerably. 

DART  has  shown  that  technology  can  rapidly 
respond  to  the  needs  of  deployment 
resequencing.  The  Rome  Laboratory/D  ARP  A 
Planning  Initiative  will  address  the  entire 
spectrum  of  Strategic  Deployment  Planning 
requirements.  Current  work  in  distributed 
planning,  as  represented  in  Fig.  1  above,  will 
culminate  in  an  integrated  feasibility 
demonstration.  This  demonstration  will  support 
concurrent  planning  at  physical  distributed  sites 
at  Hawaii,  St.  Louis,  Rome  and  Washington, 
DC.  The  demonstration  scenario  will  support 
simultaneous  activities  such  as  occurred  during 
Desert  Storm  with  the  noncombatant  action  in 
the  Philippines,  Operation  Fiery  Vigil, 
requiring  simultaneous  support  from 
USTRANSCOM. 


Knowledge  Based  Systems  Engineering 
(KBSE) 

The  focus  of  the  KBSE  thrust  is  on  the 
development,  exploitation  and  demonstration  of 
technology  and  tools  to  support  design  and 
implementation  of  robust,  real-time,  large-scale 
knowledge-based  systems.  This  includes 
facilitating  the  use  of  advanced  interface 
technology  in  complex  C3I  applications 
requiring  natural  modes  of  expression  and  a 
deeper  level  of  interaction  between  the  system 
and  the  user.  The  goal  is  to  move  from 
systems  with  a  single  type  of  information 
representation  and  reasoning  strategy  to 
designs  which  integrate  multiple  intelligent 
system  schemes,  integrated  with  conventional 
computing  algorithms  where  appropriate,  and 
on  a  much  larger  scale  than  currently  possible. 

Under  a  current  effort,  a  testbed  environment 
for  design,  rapid  integration  and  evaluation  of 
large  scale  knowledge-based  systems  is  being 
developed.  The  Advanced  AI  Technology 
Testbed  (AAl  l  l'J  will  support  rapid  integration 


of  heterogeneous  knowledge-based  and 
conventional  subsystems  and  will  include 
capabilities  for  instrumentation  and  comparative 
analysis  of  alternative  schemes.  It  will  provide 
the  Air  Force  a  facility  for  developing  and 
testing  solutions  to  complex  decision  support 
systems  involving  the  integration  of 
knowledge-based  and  conventional  software 
modules  as  part  of  the  system  design.  Central 
to  the  AAITT  concept  is  the  KBSE's 
Knowledge-Based  simulation  research  in- 
house  effort.  This  R&D  is  concerned  with  the 
development  and  demonstration  of  advanced 
simulation  techniques,  providing  a  more 
flexible  and  dynamic  environment  needed  for 
"what  if  training  and  the  exercising  of 
integrated  decision  aid  components. 


Figure  2.  AAITT  Testbed  Concept 
AAITT  CONCEPT 

Another  effort  is  attempting  to  promote  and 
facilitate  the  use  of  advanced  interface 
technology  and  natural  language  processing  in 
future  complex  and  intelligent  Air  Force 
applications.  Interfaces  to  AI  systems  must 
become  more  transparent  to  the  user  allowing 
natural  modes  of  expression  and  a  deeper  level 
of  interaction  to  take  place  between  the  system 
and  user  taking  advantage  of  the  intelligent 
capabilities  of  each.  This  activity  addresses  not 
only  the  issues  which  will  enable  optimal 
interface  design,  but  also  the  practical  aspects 
which  allow  designers  to  use  advance  interface 
technology  in  systems  presently  being 
developed.  Natural  language  processing 
technology  is  being  explored  for  use  in 
explanation  capabilities  of  knowledge  based 
systems  and  natural  language  understanding  of 
intelligence  messages. 
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Under  the  KBSE  thrust,  several  tools  have 
been  developed  and  demonstrated  including  a 
reasoning  with  uncertainty  tool,  the  AAITT, 
and  tools  for  reasoning  about  models  and 
exploitation  of  parallelism.  Techniques  for 
acquisition  and  management  of  large  scale 
knowledge  bases  have  been  embodied  in  tools 
developed  under  this  program. 

Three  demonstration  systems  with  incremental 
up^ades  are  planned  for  the  AAITT.  The  first, 
delivered  to  the  government  in  September  of 
1991,  implemented  a  core  C2I  testbed,  which 
included  a  mission  planner,  ORACLE 
database,  and  Tactical  simulation,  on  top  of  a 
distributed  processing  substrate  that  allowed 
for  flexible  interchange  of  component 
subsystems.  The  second  system,  delivered  in 
the  September  of  1992,  includes  measurement, 
instrumentation  and  monitoring  capabilities  and 
will  be  demonstrated  solving  a  significant 
tactical  C21  problem.  The  third  and  final 
system,  scheduled  for  delivery  in  the  fall  of 
1993  will  demonstrate  the  testbed  capabilities 
on  a  domain  outside  of  C3I  and  will  include 
modeling  capabilities  that  allow  the  application 
developer  to  "  test  drive"  a  system  before  it  is 
actually  built. 


Knowledge  Based  Software 
Assistance(KBSA) 

In  1982,  the  Rome  Laboratory  (formerly  the 
Rome  Air  Development  Center)  initiated  a 
program  to  develop  a  knowledge-based  system 
addressing  the  entire  software  system  life 
cycle.  The  Knowledge-Based  Software 
Assistant  (KBSA),  a  retreat  from  pure 
automatic  programming,  is  based  upon  the 
belief  that  by  retaining  the  human  in  the  process 
many  of  the  unsolved  problems  encountered  in 
automatic  programming  may  be  avoided.  It 
proposes  a  new  programming  paradigm  in 
which  software  activities  are  machine  moated 
and  supported  throughout  the  life  cycle.  The 
underlying  concept  of  the  KBSA,  described  in 
the  original  1983  report  entitled,  "Report  on  A 
Knowledge-Based  Software  Assistant,"  is  that 
the  processes  in  addition  to  the  products  of 
software  development  will  be  foimalized  and 
automated.  This  enables  a  knowledge  base  to 
evolve  that  will  capture  the  history  of  the  life 
cycle  processes  and  support  automated 
reasoning  about  the  software  under 
development.  The  impact  of  this  formalization 
of  the  processes  is  that  software  will  be  derived 
from  requirements  and  specifications  through  a 


series  of  formal  transformations.  Enhancement 
and  change  will  take  place  at  the  requirements 
and  specification  level  as  it  will  be  possible  to 
"replay"  the  process  of  implementation  as 
record^  in  the  knowledge  base.  KBSA  will 
provide  a  corporate  menxxy  of  how  objects  arc 
related,  the  reasoning  that  took  place  during 
design,  the  rationale  behind  decisions,  the 
relationships  among  requirements, 
specifications,  and  code,  and  an  explanation  of 
the  development  process.  This  assistance  and 
design  capture  will  be  accomplished  through  a 
collection  of  inte^ated  life  cycle  facets,  each 
tailored  to  its  particular  role,  and  an  underlying 
common  environment 


The  goals  of  the  KBSA  program,  as  stated  in 
the  1983  report,  are  to  provide  an  environment 
where  design  will  take  place  at  a  higher  level  of 
abstraction  than  is  current  practice. 
Knowledge- based  assistance  mediates  all 
activities  and  provides  process  coordination 
and  guidance  to  users,  assisting  them  in 
translating  informal  application  domain 
representations  into  formal  executable 
specifications.  The  majority  of  software 
development  activities  are  moved  to  the 
specification  level  as  early  validation  is 
provided  through  prototyping,  symbolic 
evaluation,  and  simulation.  Implementations 
are  derived  from  formal  specifications  through 
a  series  of  automated  meaning  preserving 
transformations,  insuring  that  the 
implementation  correctly  represents  the 
specification.  Post  deployment  support  of  the 
developed  application  system  is  also  be 
concentrated  at  the  requirements/specification 
level  with  subsequent  implementations  being 
efficiently  generated  through  a  largely 
automated  "replay"  process.  This  capability 
provides  the  additional  benefit  of  reuse  of 
designs  as  families  of  systems  can  spawn  from 
the  original  application.  Management  policies 
are  also  formally  stated  enabling  machine 
assisted  enforcement  and  structuring  of  the 
software  life  cycle  processes. 


The  techniques  for  achieving  these  goals  are: 


Formal  representation  and  automatic 
recording  of  all  the  processes  and  objects 
associated  with  the  software  life  cycle. 
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Figure  3.  KBSA  Concept  Model 


An  Extensible  knowledge-based 
representation  and  inference  capability  to 
represent  and  utilize  knowledge  in  the  software 
development  and  application  domains. 


A  wide-spectrum  Reification  language 
in  which  high-level  constructs  are  freely  mix^ 
with  implementation-level  constructs. 


Coneemess  preserving  transformations 
that  enable  the  iterative  refinement  of  high-level 
constructs  into  implementation-level  constructs 
as  the  KBSA  carries  out  the  design  decisions  of 
the  developer. 


The  strategy  proposed  in  1983  to  achieve  the 
goals  of  the  KBSA  was  to  first  formalize  each 
stage  of  the  present  software  life  cycle  model, 
wi^  parallel  developments  of  technology  and 
knowledge  bases  for  each  particular  stage. 
Supporting  technology  was  also  to  be  the 
subject  of  concurrent  research  and  development 
efforts  with  periodic  integration  efforts  or 
"builds"  to  assess  progress  and  identify 
deficiencies.  Although  resource  limitations 
have  precluded  the  multiple  parallel  research 


thrusts  of  a  magnitude  originally  proposed, 
initial  products  of  the  program  have  emerged 
with  the  successful  completion  of  efforts  which 
model  and  automate  requirements  definition, 
system  specification,  performance  optimization 
and  project  management.  Supporting 
technology  has  also  been  investigated  and 
defined  which  will  form  the  core  of  the  KBSA 
and  will  be  used  in  merging  and  managing  the 
activities  and  processes  of  the  various  users. 
The  following  paragraphs  will  provide  a  brief 
description  of  the  basic  approach  of  each 
research  effort  and  resulting  products. 


The  first  area  to  be  addressed  by  the  KBSA 
program  was  that  of  project  management.  In 
1984  our  program  began  defining  a  Project 
Management  Assistant  formalism  and 
constructing  a  working  prototype.  The  effort 
goals  were  to  provide  knowledge-based 
assistance  in  the  management  of  project 
planning,  monitoring,  and  communications. 
Planning  assistance  enables  the  structuring  of 
the  project  into  individual  tasks  and  then 
scheduling  and  assigning  these  tasks.  Once 
planned  a  project  must  be  monitored.  This  is 
accomplished  through  cost  and  schedule 
constraints  and  the  enforcement  of  specific 
management  policies.  PMA  also  provideses 
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user  interaction  in  the  form  of  direct 
queries/updates  and  various  graphics 
representations  such  as  Pert  Charts  and  Gantt 
Charts.  PMA  is  distinguished  from 
conventional  management  tools  because  not 
only  does  PMA  handle  user  defined  tasks,  but 
it  also  understands  the  products  and  implicit 
relationships  among  them  (eg.  components, 
tasks,  requirements,  specification,  source  code, 
test  cases,  test  results,  and  milestones). 
Contributions  of  the  PMA  include  the 
formalization  of  the  above  objects,  the 
development  of  a  powerful  temporal 
representation  for  dependency  relationships 
between  software  development  objects,  and  a 
mechanisms  for  expressing  and  enforcing 
project  policies.  The  initial  PMA  effort  was 
completed  in  1986.  A  subsequent  PMA 
contract  was  initiated  in  Novemb^  1987.  Its 
goals  were  to  continue  the  evolution  of  PMA, 
expanding  the  formalized  knowledge  of  project 
management  to  provide  enhanced  capabilities 
and  to  implement  PMA  as  an  integral  pan  of  a 
full-scale  conventional  software  engineering 
environment  called  SLCSE  (Software  Life- 
Cycle  Support  Environment).  This  work 
recently  completed  in  the  summer  of  1990. 


In  1985  began  work  on  the  Knowledge  Based 
Requirements  Assistant  (KBRA).  Central  to 
the  KBRA  was  dealing  with  the  informal 
nature  of  the  requirements  definition  process 
including  incompleteness  and  inconsistency. 
See  Figure  3  above.  In  the  KBRA 
environnwnt  requirements  are  entered  in  any 
desired  order  or  level  of  detail  using  one  of 
many  differing  views  of  the  application 
problem.  The  KBRA  is  then  responsible  for 
doing  the  necessary  bookkeeping  to  allow  the 
user  to  manipulate  the  requirements  while  it 
maintains  consistency  among  requirements. 
Capabilities  included  in  the  KBRA  are  support 
for  multiple  viewpoints  (eg.  data  flow,  control 
flow,  state  transition,  and  functional  flow 
diagrams),  management  and  editing  tools  to 
organize  requirements,  and  the  support  for 
constraints  and  requirements  that  are  not 
functional  in  nature  through  the  use  of 
spreadsheet  and  natural  language  notations. 
Other  capabilities  of  the  KBRA  include  the 
analysis  of  requirements  to  identify 
inconsistency  and  incompleteness,  and  the 
ability  to  generate  explanations  and  descriptions 
of  the  evolving  system.  As  previously 
indicated,  the  primary  issue  addressed  by  the 
KBRA  was  handling  the  informality  of 
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incomplete  user  descriptions  while  building  and 
maintaining  a  consistent  internal  rep’esentadon. 
This  was  accomplished  through  the  use  of  a 
representation  providing  truth  maintenance 
support  including  default  reasoning, 
dependency  tracing,  and  local  propagation  of 
constraints.  Through  these  mechanisms  the 
KBRA  was  able  to  provide  an  application 
specific  automatic  classification  which  is  used 
to  identify  missing  requirements  by  comparing 
current  input  against  existing  requirements 
contained  in  the  knowledge  base. 


Development  of  the  KBSA  Specification 
Assistant  began  in  198S.  The  goal  of  the 
Specification  Assistant  is  to  facilitate  the 
development  of  formal  executable 
specifications  of  software  systems,  a  task  that 
otherwise  is  as  difficult  as  actually  writing 
system  code.  It  supports  an  evolutionary 
activity  in  which  the  system  specification  is 
incrementally  elaborated  as  the  user  chooses 
among  design  alternatives.  An  executable 
formal  specification  language  combined  with 
symbolic  evaluation,  specification  paraphrasing 
and  static  analysis  allow  early  design  validation 
hv  providing  the  user  an  evolving  prototype  of 
the  system  dong  with  English  descriptions  and 
consistency  checking  throughout  its  design. 
Specification  Assistant  capabilities  are  built  on 
the  Lisp  based  APS  language  and  the  CLF 
development  environment  and  utilize  a  variety 
of  tools  to  support  the  user.  A  formal 
specification  language  called  Gist  is  supported 
by  a  number  of  facilities  which  aid  the 
development  of  specifications.  One  facility 
peculiar  to  the  Specification  Assistant  is  the 
support  for  specification  evolution  in  the  form 
of  high-level  editing  commands,  also  known  as 
evolution  transformations.  These  commands 
perform  stereotypical,  meaningful  changes  to 
the  specification.  They  differ  from 
conventional  "correctness-preserving" 
transformations  in  that  they  are  specifically 
intended  to  change  the  meaning  of 
specifications,  but  in  specific  ways.  In 
addition  to  the  top  down  evolution  of 
specifications  supported  by  the  high-level 
editing  commands,  the  Specification  Assistant 
supports  the  building  of  a  specification  from 
smaller  specifications  (i.e..  the  reuse  of 
previously  defined  specifications)  with  a  set  of 
view  extraction  and  merging  tools. 

In  1988  Rome  Lab  initiated  an  effort  to 
combine  the  requirements  acquisition  process 
with  that  of  formal  system  specification.  This 


effort  merges  the  developments  of  the  KBRA 
and  Specification  Assistant,  spanning  all  the 
activities  needed  to  derive  a  complete  and  valid 
design  from  initial  user  requirements  in  one 
system  called  ARIES. 

The  development  of  an  assistant  to  guide 
designers  in  performance  decisions  at  many 
levels  in  the  software  development  cycle  was 
the  goal  of  a  1985  contract  with  one  of  a  small 
cadre  of  research  institutes  showing 
commitment  and  expertise  in  this  area.  This 
research  produced  a  prototype  system  which 
takes  as  input  a  high  level  program  written  in  a 
wide-spectrum  language  and  following  a 
combination  of  automatic,  performance-based, 
and  interactively-guided  transformations, 
produces  efficient  code.  The  Performance 
Assistant  supports  the  application  of  a  variety 
of  analysis  and  optimization  techniques  broken 
into  the  two  general  categories  of  control 
optimizations  and  data  optimizations.  The 
control  optimizations  include  finite 
differencing,  iterator  inversion,  loop  fusion, 
and  dead  C(^e  elimination.  Data  optimization 
includes  data  structure  selection,  which 
implements  a  program’s  data  objects  using 
efficient  structures,  and  copy  optimization, 
which  eliminates  needless  copying  of  large  data 
objects.  A  subsequent  effort  to  develop  an 
independent  tool  that  would  assist  in  the 
development  of  high  performance  Ada  software 
was  initiated  in  1991.  This  effort  seeks  to 
enhance  the  capabilities  of  the  earlier  effort  by 
making  them  more  robust  and  portable  to  more 
conventional  software  development 
environments,  and  by  enabling  the  design  and 
generation  of  optima  Ada  code.  The  product 
of  this  effort  is  scheduled  for  delivery  at  the 
beginning  of  1994. 

An  effort  to  define  the  requirements  for  a 
Framework  sufficient  to  support  the  many 
varying  facets  of  assistance  provided  by  the 
KBSA  commenced.  The  goal  of  this  effort 
was  to  define  a  unifying  framework  which 
would  support  an  object  base  with  a  tightly 
integrated  logical  inference  system, 
configuration  management,  activity 
coordination,  and  user  interface  for  the  KBSA. 
This  Framework  sought  to  provide  a  common 
reference  for  other  facet  developers  which 
when  followed  would  allow  the  sharing  of 
information.  Also  included  in  the  effort  was 
the  goal  of  demonstrating  the  integration  of 
multiple  KBSA  facets  and  the  specification  of 
common  support  capabilities.  This  effort 
resulted  in;  a  Framework  based  upon  a  merging 


of  the  Common  Lisp  Object  System  (CLOS) 
with  the  LogLisp  programming  environment; 
the  KBSA  User  Interface  Environment 
(KUIE);  and,  a  preliminary  Configuration  and 
Change  Management  (CMM)  model  for  the 
KBSA.  LogLisp  is  a  language  developed  at 
Syracuse  University  that  extends  a  total  Lisp 
environment  with  logic  programming 
capabilities.  KUIE  is  a  highly  object  oriented 
system  based  on  CLOS  and  the  XI 1  Window 
System  f(»’  constructing  user  interfaces. 

The  creation  of  an  Assistant  to  support  the 
transforming  of  formal  specifications  into  low 
level  coded  was  the  goal  of  an  effort  started  in 
1988.  The  Development  Assistant,  sharing 
many  capabilities  with  the  Performance 
Assistant,  is  based  the  Kestrel  Interactive 
Development  System  (KIDS)  and  is  written  in 
the  Refine  language.  The  system  supports  the 
construction  of  formal  model  of  the  application 
domain  including  the  specification  of  the  target 
system's  desired  behavior  and  the  application 
of  transformations  to  the  specification  to 
produce  detailed  code.  The  provided  set  of 
transformations  encode  design  and  optimization 
knowledge,  allowing  the  user  to  mechanically 
make  high-level  design  decisions  which  the 
system  systematically  applies.  A  facility  is  also 
provided  which  records  derivations  and 
provides  the  basis  for  future  "replay”,  a 
fundamental  concept  of  the  KBSA.  The 
Development  Assistant  was  delivered  to  the 
Rome  Laboratory  in  late  summer  1991. 

One  of  the  original  concepts  which 
distinguished  the  KBSA  was  that  of  activity 
and  communication  coordination.  This 
supporting  technology  was  the  subject  of  an 
effort  undertaken  by  Software  Options  in  1988. 
The  goal  of  this  research  was  to  define  a 
formalism  with  a  graphical  syntax  that  could  be 
used  to  specify  and  enforce  the  coordination  of 
the  many  KBSA  activities  and  communications 
allowing  the  programming  of  the  KBSA 
processes.  This  effort  resulted  in  the 
development  of  "Transaction  Graphs,"  a 
formalism  for  specifying  processes.  Related  to 
activity  coordination  is  the  problem  of  change 
and  configuration  management.  In  mid  1991, 
Software  ^tions  began  the  task  of  merging  the 
formalisms  for  activity  coordination  and 
configuration  management.  Using  Transaction 
Graphs  and  their  existing  "Artifacts" 
configuration  management  system  they  are 
developing  a  unified  formalism  for 
coordinating  and  managing  the  products  and 
processes  of  the  KBSA  par^igm. 


In  1988  the  development  started  on  a  total  life 
cycle  demonstration  of  the  concepts  of  the 
KBSA.  This  development  provides  a  broad 
concept  coverage  but  a  shallow  functionality 
demonstration  capability  for  a  narrow  problem 
domain.  The  current  KBSA  Concept 
Demonstration  system  combines  preliminary 
capabilities  from  the  ARIES,  Development,  and 
Project  Management  assistants  and  includes 
example  developments  from  an  Air  Traffic 
Control  domain.  It  allows  the  demonstration  of 
refinement  of  requirements  and  specifications, 
the  complete  capabilities  of  the  Project 
Management  Assistant  including  the  automatic 
creation  of  tasks  as  the  design  progresses,  and 
the  automatic  generation  of  Lisp  c<^e  from  the 
specifications.  Many  additional  capabilities  are 
available  for  examining  and  manipulating  both 
informal  arid  formal  representations  of  design 
including  hypertext,  multiple  graphical 
representations,  English  like  explanations,  and 
the  simulation  of  application  system  execution. 
The  final  product,  delivered  in  October  of 
1992,  also  addresses  the  formal  verification  of 
specifications. 

Current  program  activities  include  the 
development  of  an  initial  operational  capability, 
the  KBSA  Advanced  Development  Model 
(ADM),  and  a  broad  spectrum  of  research 
directed  toward  technology  and  capability 
deficiencies.  The  ADM  will  be  the  first  attempt 
at  integrating  the  KBSA  technologies  to  form  a 
working  environment.  The  work  includes 
design  and  development  of  a  robust 
environment  of  acceptable  performance 
combined  followed  by  evaluation  through 
development  of  a  moderate  sized  "real" 
application.  This  work  will  begin  in  December 
of  1992  with  completion  four  years  later. 
Award  of  a  range  of  efforts  arising  from  the 
current  Program  Research  and  Development 
Announcement  (PRDA)  is  anticipated  in  the 
spring  of  1993.  These  efforts  will  continue  the 
evolution  and  refinement  of  KBSA  technology 
and  it  is  hoped  that  close  coordination  of  these 
efforts  with  that  of  developing  an  operational 
capability  will  accelerate  both  technical 
accomplishment  and  acceptance. 

Although  the  KBSA  is  much  closer  to  fruition 
than  true  "automatic  programming"  and  much 
optimism  exists  as  evidenced  above,  it  is  an 
ambitious  project  and  sought  after  results 
should  not  be  expiected  soon.  Future  efforts  of 
the  KBSA  program  include  the  development  of 
an  operational  KBSA  system  starting  in  1992 
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and  the  continued  evolution  of  existing 
components  and  supporting  technology.  The 
desire  for  more  immediate  benefits  has  been 
addressed  by  producing  "spin-off  tools  for 
conventional  environments,  hosting  annual 
workshops,  and  forming  the  KBSA 
Technology  Transfer  Consortium  providing 
industry  immediate  access  to  the  technology 
and  tools  of  the  program.  The  goal  of  these 
activities  is  to  attain  an  initial  operational 
capability  of  the  KBSA  by  late  1996^  or  early 
1997. 


Summary 


Rome  Lab's  program  is  attempting  to  enhance 
current  AI  technology  for  use  in  large,  real-time 
mission  critical  systems  and  developing  the 
software  tools  that  improve  and  enable  the 
development,  fielding  and  maintenance  of  these 
Al-based  systems.  This  program  is  addressing 
critical  technology  shortfdls  with  respect  to  Air 
Force  mission  needs  and  advancing  that 
technology  in  the  three  thrust  areas  of 
knowledge  based  planning,  knowledge  based 
systems  engineering  and  knowledge  based 
software  assistance.  Evaluation  and 
demonstrations  of  the  technology  and  tools  has 
and  will  continue  to  be  perform^  in  the  context 
of  C3I  mission  functions. 
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Discussion 


Questioii  D.  NAIRN 

How  focussed  a  soiutioii  is  DART?  Has  it  any  general  appikadoa?  Wbat  vaikiabon  is  needed  before  operational  use? 
Reply 

In  general.  DART  is  simply  a  grapbical  interface  u>  an  ORAO  -E  database.  In  particular,  it  focuses  on  and  displays  time 
windows :  early,  latest  slait/arrival  dates  and  transpoHation  durations.  Tbe  simulation  aspects  of  DART  is  a  general 
feasibility  analysis  tool  for  determining  the  percentage  of  on-time  arrivals. 

Validation,  due  to  the  extremely  short  development  time,  was  stress  testing  and  user  participation  during  development. 
Question  D.  NAIRN 

Have  you  studied  what  percentage  of  maintenance  tasks  involve  changes  to  the  specifications  and  what  percentage  are 
retricted  to  implementation,  eg  hardware  variants,  bug  fixes,  etc? 

Reply 

In  short,  no.  But  my  general  feeling  is  that  vtuiants  and  conTigurations  should  be  documented  as  rctjuirements  and  hence 
become  part  of  tbe  spedCkatkm  as  appropriate. 

No  bugs  means  no  bug  fixes.  "Bugs'  that  are  a  fault  of  tbe  code-generation  process  would  indicate  a  fault  in  the  KBSA 
(or  in  rare  cases,  in  the  band-coding :  this  should  be  avoided!).  Other  bugs  may  be  results  of  incomplete  or  iixxmsistcnt 
requirements.  These  types  of  bugs  should  be  delected  prior  lo  coding,  although  incompleteness  of  requirements  is 

difficult  to  delea. 
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ALSNIA  '  N«rvlano  Plant  ia  nainly  involvad 
In  th«  davalopmant  of  conplax  avionic 
aystams,  of  which  aoftwara  ia  aaaantial 
componant,  oftan  praaanting  aafaty  critical 
faaturaa.  Inadaquacy  of  tha  traditional 
tachniquaa  and  mathoda  impoaa  to  aupport 
tham  with  additional  rafinamant  tools  to 
build  tha  product  aafaty  durinq  davalopinq 
phaaas . 

Tha  papar  daacribaa  a  mathodoloqical 
approach  for  tha  systamatic  idantification 
and  claaaificatioA  of  tha  affacta  cauaad  by 
potantial  softwara  failuras.  Tha  potantial 
aoftwara  failuraa  ara  idantifiad  avaluating 
tha  affacta  that  would  ba  producad  by 
incorract  outputs  on  tha  othar  aoftwara 
parta  and  on  tha  axtarnal  anvironmant. 
Furtharifiora,  tha  proposad  approach  allows  to 
avaluata  tha  nacaaaity  to  introduca  fault* 
toleranca,  racovary  and  backup  procaduraa, 
and  to  dafina  tha  adaquata  quantity  and 
typology  of  tasting  and  quality  activitias. 

1.  XlinbODQCTlCNf 

Tha  papar  daacribaa  a  qualitativa 
methodology,  utilizad  in  Alania,  to  faca 
ayatenisuically  tha  idantification  and 
classification  c<f  the  affacta  cauaad  by 
potantial  softwara  failures  and  details  ita 
operating  steps,  which  mainly  consists  of: 
functionality  analysis  and  architectural 
design,  potential  failure  mode 
idantification,  affacta  evaluation, 
criticality  categories  assignation,  and 
corrective  actions  idantification . 

Tha  utilized  methodological  approach 
consists  essentially  of  tha  analysis  of  each 
software  requirement  and  of  each 
architectural  component,  with  tha  purpose  to 
evaluate  the  effects  that  would  ba  producad 
by  incorract  outputs  on  the  othar  software 
parts  and  on  tha  external  environment. 

As  a  result  of  the  inherent  complexity  of 
tha  softwara  development  process,  developers 
have  plenty  of  opportunities  to  make  errors. 
The  total  nufidE>ar  of  defects  injected  into 
software  not  intentionally  by  analysts, 
designers  and  programmers  from  requirements 
determination  to  delivery  is  vary  large. 

Moat  of  these  errors  are  removed  before 
delivery  through  salf*checking  by  analysts 
and  programmers,  design  reviews, 
walkthroughs,  inspections,  testing . 

The  effort  to  remove  and  prevent  defects 
before  delivery  is  more  intense  in  the  case 
of  application  types  where  tha  error  has 
serious  consequences,  even  life  and  death. 


than  it  is  in  applications  where  tha 
consequences  ara  less  drastic. 

Reducing  errors  is,  of  course,  an  extensive 
effort,  embracing  every  aspect  of  software 
davalopaant. 

Tha  currant  methods,  utilized  for  tha 
softwara  production  in  applications  with 
criticality  characteristics,  consist  of 
activities  of  davalopraant  and  control  during 
tha  whole  life  cycle,  and  affect 
considerably  cost  and  time. 

They  interest  uniformly  all  the  softwara 
functionalities,  without  distinguishing 
between  the  elements. 

The  actual  aim  is  to  minimize  the  most 
critical  functionalities  defects  only,  and 
to  operate  during  tha  requirements  analysis 
and  design. 

Tha  critical  meaning  is  defined  regarding 
the  actual  context,  then  there  will  be 
defined  critical  the  functionalities  with 
effect  on  mission  objectives,  on  human  life, 
on  financial  objectives,  or  on  environment, 
at  cetera. 

So,  the  methodology  is  of  general 
applicability,  even  if  below  its  description 
refers  to  a  context  in  which  the  software 
functions  criticality  is  identified  basing 
on  the  safety. 

Linking  with  the  avionic  equipments  failures 
nature,  there  will  be  the  software  risk 
class  1.  2  and  3. 

Consequently,  the  software  failures 
involving  in  the  software  risk  classes  have 
an  analog  classification:  failure  class  1,  2 
and  3. 

2.  PBOdDOU  DISCUPTIOV 

The  methodology  requires  as  background  the 
quality  standard  concepts,  among  which  the 
Alenia  Quality  Manual  appears  and  consists 
of  the  principal  military  and  civil  rules 
guide  lines. 

The  methodology  aim  is  to  support  the 
development  of  software  for  a  safety*related 
system. 

Furthermore,  it  starts  from  the  initial 
hypothesis  which  takes  for  known  the  output 
characteristics,  that  go  from  the  software 
environment  to  the  External  Interface.  In 
detail,  it  must  be  known  before  the 
criticality  risk  class  of  all  the  outputs 
towards  the  External  Interface.  The  risk 
class  may  be  1,  2  or  3. 

Basing  on  the  output  risk  classes,  the 
functionalities  and  CSUs  risk  classes  are 
assigned,  during  the  software  requirements 
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Figure  1  -  Softwara  davaloptneot  proceaa 


analysis  and  the  detailed  design  phases 
respectively. 

The  methodology  becomes  part  of  the  software 
life  cycle  (Figure  1) .  It  is  applied  during 
the  analysis  and  detailed  design  phases 
profitably,  while  it  furnishes  useful 
information  for  the  choice  of  the  strategy 
to  adopt  during  the  coding  and  test  phases. 

2.x  Software  aegoireaents  Analyaia  Phaaa 

(Functionalities  failures  analysis) 

In  this  phase  the  functionalities  risk 
classes  are  identified  and  then  an  eventual 
fault-tolerance  mechanism  is  introduced. 

At  the  beginning,  the  software  requirements 
are  identified  and  analysed.  The  Structured 
Analysis  allows  to  do  that,  because  it  puts 
particular  attention  to  the  input  and  output 
data  flows,  utilized  in  the  next  steps. 

Another  analysis  may  be  utilized,  on 
condition  that  it  points  out  the  data  flows; 
or,  an  already  realized  analysis,  that 
follows  the  previous  requirements,  may  be 
utilized  however. 

The  analysis  continues  until  the  basic 
functionalities  are  identified. 

The  analysis  is  satisfactory  when,  for  each 
identified  functionality,  a  description  of 
what  is  required  to  be  executed  is 
furnished.  So,  at  the  analysis  end,  it  is 
possible  to  obtain  a  complete  vision  of  the 
data  flows  and  how  they  have  to  be  treated; 
furthermore,  it  is  possible  to  furnish  a 
first  sign  about  the  control  flows,  in  fact 
sometimes  the  information  treatment  sequence 
is  pointed  out. 

Mow,  the  steps  to  be  followed  are  described 
and  the  Structured  Analysis  is  applied. 

When  the  wished  detail  is  reached,  the  risk 
class  1  and  2  outputs  towards  External 
Interface  are  detected. 

The  risk  class  3  outputs  aren’t  considered. 


Externa)  Computer  Software  External 
Interface  Interlace 
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For  OAch  idonti£i«d  output,  tho  ««t  of 
functioAoIltloa  thot  lo«d  to  tho  output 
crMtioo  i«  poiotod  out;  in  th«  oxaiaplo 
ono  aot  conaista  of  tho  Functionalitiaa  n.l 
n.2  *  n.3,  bocauaa  on. 3  ia  of  riak  claaa 

2. 

Tho  functionalitiaa  aota  may  bo  roducod 
f urthormoro,  if  only  tho  functionalitiaa 
that  load  to  tho  risk  claaa  1  outputa  aro 
conaidorod.  Thia  choico  muat  bo  dona  baaing 
on  tho  apocific  roquirooMnta  of  oach 
pro joct . 

For  oach  provioua  idontifiod  functionalitiaa 
aot  and  atarting  from  tho  firat 
functionality/  tho  following  atopa  aro 
fulfilled: 

1.  Ootormino  if  an  unoxpoctod  output  from 
tho  conaidorod  functionality  or  tha 
output  miaaing  whan  oxpoctod  can  affect 
tho  laat  output . 

Thia  conaidoration  ia  roalizod  atarting 
from  tho  initial  hypothoaia  that  tho 
other  functionalities  run  properly  and 
baaing  on  tho  knowledge  of  what  ia  tho 
behaviour  required  for  the 
functionalities/  that  are  executed  after 
the  laat  one  considered. 

2.  If  tho  answer  ia  positive,  tho  considered 
functionality  inherits  the  last  output 
risk  class  (1  or  2) . 

3.  If  the  considered  functionality  ia  of 
risk  claaa  1  or  2,  then  it  ia  posaible  to 
introduce  new  fault'-tolerance 
requirements,  to  manage  the  potential 
failures . 

After  the  fault*‘tolerance  mechanism  has 
boon  introduced,  the  functionality  risk 
class  can  decrease.  In  this  case,  it  ia 
marked  with  an  asterisk. 

All  the  functionalities,  that  are 
previously  analysed  and  involved  in  the 
fault'tolerance  mechanism,  are  evaluated 
again . 

4.  If  the  considered  set  contains  other 
functionalities,  then  consider  the  next 
functionality  and  restart  from  the  point 
2.1.1;  otherwise,  execute  the  steps  from 
2.1.1  to  2.1.4  on  the  next  set,  until  all 
the  previously  identified  sets  are 
considered. 

After  the  steps  from  1  to  4  have  been 
executed  for  each  functionalities  set,  it 
may  occur  the  need  to  check  the  analysis,  or 
part  of  it,  so  that  the  basic 
functionalities  are  reorganized  basing  on 
their  risk  class,  Isolating,  where  it  is 
possible,  the  risk  class  1  or  2 
functionalities  sets. 

At  this  time,  if  it  is  necessary,  ,the  steps 
from  1  to  4  are  reapplied  on  the  just 
identified  functionalities  sets. 

2.2  D«t«iled  Design  Phase 
(CSUs  failures  analysis) 

During  the  detailed  design  phase  the  risk 
classes  of  the  CSUs  are  detected. 


It  ie  suggeated  to  apply  the  methodology 
during  this  phase,  also  if  it  has  just  been 
applied  during  the  requirements  analysis.  In 
fact,  it  allows  to  distinguish  the  CSUs  with 
greater  risk  class  (1  or  2)  furthermore, 
iiiq>rovlng  the  previous  analysis  result. 

from  the  requirements  analysis  it  passes  to 
the  preliminary  design,  conforming  with  the 
obtained  results.  In  this  phase  the 
methodology  isn't  applied,  because  it 
doesn't  add  relevant  information  respect  the 
previous  phase. 

from  the  preliminary  design,  it  passes  to  a 
detailed  design,  that  defines  the  CSUs 
leaves.  The  Structured  Design  is  indicated 
for  this  scope,  but  another  design  type  may 
be  utilized  too,  in  which  tha  data  and 
control  flows  are  pointed  out. 

As  in  the  requirements  analysis  phase,  also 
in  this  case  a  previously  executed  design 
may  be  utilized,  on  condition  that  it 
fulfills  the  flows  requirements. 

The  design  is  satisfactory  when,  for  each 
CSU,  it  provides  a  description  of  the  data 
management  and  control. 

Now,  the  steps  to  be  followed  are  described, 
and  the  Structured  Design  is  applied. 

When  the  wished  detail  is  achieved,  the  risk 
class  1  or  2  outputs  towards  the  External 
Interface  are  pointed  out. 

The  risk  class  3  outputs  aren't  considered. 
The  output  risk  class  muse  be  defined 
conforming  with  the  analysis  definitions. 

for  each  identified  output,  the  sets  of  CSUs 
that  lead  to  the  output  creation  are  pointed 
out;  in  the  example,  one  set  consists  of  the 
CSUs  1.1.  -  1.1.2  -  1.2  -  1.3,  because  the 
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FlQUfB  7  -  Level  2 


output  ol.3  is  of  risk  cXaas  2. 

Specific  project  demands  can  require  to 
reduce  the  nunUMr  of  the  CSUs  sets  to  be 
considered,  defining  more  restricted 
constraints . 

For  each  previously  identified  CSCJs  set, 
starting  from  the  first  CSU,  the  following 
steps  are  fulfilled: 

1.  Determine  if  an  unexpected  value  of  the 
output,  or  the  output  missing  when 
expected,  or  the  unexpected  exit  of  the 
output,  can  affect  the  final  output 
considerably. 

Furthermore,  while  at  requirements 
analysis  level  all  be  defined,  at 

design  level  the  information  treatment 
description  is  complete. 

2.  If  the  answer  is  positive,  the  considered 
CSU  inherits  the  last  output  risk  class 

(1  or  2) . 

If  the  considered  CSU  risk  class  is  1  or 
2,  a  new  row  in  APOSF  (Analysis  of  the 
possible  Software  Failures)  Table  is 
initialized. 

3.  If  the  considered  CSU  risk  class  is  1  or 
2,  the  possible  failures  are  determined. 
More  precisely,  the  generic  failure 
situations  are: 


a)  loss  of  the  function  identified  by  the 
CSU;  for  example,  the  function  has  not 
been  activated  for  a  scheduling  error; 

b)  running  of  the  function  identified  by 
the  CSU  when  it  is  not  requested;  for 
exan^le,  there  is  an  erroneous  control 
flow,  or  there  are  temper! zat ion  or 
synchronization  errors; 

c)  the  function  identified  by  the  CSU 
doesn’t  work  correctly;  for  example, 
an  implementation  fault. 

All  the  hypothetical  failures,  the 
effects  of  each  failure  on  the  other  CSUs 
and  on  tH^'  c.xtei.nal  Interface,  and  the 
affected  CSUs  have  to  be  written  in  APOSF 
Table. 

4.  After  the  possible  failures  detection, 
when  the  considered  CSU  risk  class  is  1 
or  2,  it  is  possible  to  introduce  fault- 
tolerance  mechanisms . 

The  detected  solutions  and  the  interested 
CSUs  are  reported  in  APOSF  Table. 

Choosing  between  the  thought  solutions, 
the  more  suitable  one  for  the  current 
situation  is  identified,  and,  basing  on 
it,  the  considered  CSU  risk  class  is 
evaluated  again. 

Furthermore,  if  the  adopted  solution 
modifies  previously  analysed  CSUs,  it 
needs  to  evaluate  again  their  risk  class; 
if  their  risk  class  decreases,  mack  it 
with  an  asterisk.  After,  verify  their 
failures  effects  and  eventually  bring  up- 
to-date  APOSF  Table. 

5.  If  the  set  contains  another  CSU  to 
analyze,  consider  it  and  restart  from 
point  1;  otherwise,  apply  the  steps  from 
1  to  5  to  another  CSUs  set,  until  the 
identified  sets  finish. 

After  the  steps  from  1  to  5  are  executed  for 
all  or  part  of  the  CSUs  sets,  it  may  occur 
the  need  to  reorganize  the  design,  or  part 
of  it,  so  that  also  the  CSUs  are  reorganized 
basing  on  their  risk  class  and,  where  it  is 
possible,  the  risk  class  I  and  2  CSUs  sets 
are  isolated. 


Figure  8  -  APOSF  Table 
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At  this  point,  if  it  is  necessary,  the  steps 
from  1  to  5  are  reapplied  on  the  just 
identified  CSUs  sets. 

2.3  Othmx  Phmmmm 

In  the  Coding  and  CSU  Testing  Phase,  CSC 
Integration  and  Testing  Phase,  and  CSCI 
Testing  Phase,  the  information  present  in 
APOSF  Table  are  a  useful  means  to  plan  the 
activities . 

Indeed,  at  the  coding  phase  it  is  possible 
to  select  the  language  to  be  used  for  each 
software  part  or  the  algorhitms  to  be 
adopted,  so  that  the  response  time 
requirements  or  other  critical  constraints, 
identified  during  the  previous  phases,  are 
fulfilled. 

Furthermore,  a  scrutiny  activity  may  be 
executed  on  the  more  critical  points  for  the 
safety . 

During  the  CSU  testing  phase,  the  CSUs  sets 
to  be  considered  are  identified,  basing  on 
the  risk  class  (1,  2  and  1*,  2*) . 

In  fact,  the  infoi nation  furnished  during 
the  design  phase  allow  to  identify  the  CSUs 
to  be  controlled  much  more,  and  to  point  out 
the  more  meaningful  input  data,  so  the 
testing  time  is  reduced  and  the  safety  is 
safeguarded. 

Also  in  this  CSC  Integration  and  Testing 
Phase,  the  information  furnished  during  the 
design  phase  allow  to  identify  the  most 
critical  software  parts  to  be  considered; 
so,  the  CSUs  relations,  the  Interfaces 
between  the  CSCs  and  the  External 
Environment,  and  the  Interfaces  between  the 
same  CSCs  are  tested. 

During  the  CSCI  Testing  Phase  the 
information  obtained  from  the  requirements 
analysis  phase  may  be  utilized  to  point  out 
the  most  critical  functionalities  and  define 
the  opportune  input  sequence  and  the 
expected  outputs. 

So,  the  effort  is  concentrated  on  few 
aspects  and  the  safety  is  safeguarded 
equally. 

3.  XXAMPLS 

The  procedure  has  been  applied  on  an  avionic 
equipment,  which  transmits  data  between  the 
operator  and  the  internal  system,  and 
consists  of  hardware  and  software  parts. 

More  precisely,  it  has  been  considered  the 
equipment  software  part  which  manages  the 
information  coming  from  the  Front  Panel  and 
the  relative  information  stored  in  the 
internal  memory. 

3.1  roaotlonalltiee  failures  analysis 

The  software  requirements  analysis  has  been 
done  using  CORE  (Controlled  Requirements 
Expression) ,  which  identifies  the  input  and 
output  data  flows,  and  then  may  be 
considered  for  the  actual  context. 


It  has  been  pointed  out  a  final  output  of 
risk  class  2,  that  is  a  Flight  Safety 
Involved  Signal. 

The  sequence  of  basic  functionalities  that 
create  this  output  has  been  identified. 
Shortly,  one  functionality  tests  if  there  is 
a  new  input  from  the  Front  Panel  Interface; 
if  the  answer  is  positive,  the  next 
functionality  converts  the  data  from  the 
Front  Panel  format  into  the  final  output. 
Afterwards,  the  new  converted  data  are 
loaded  by  another  functionality  into  another 
memory  part. 

By  applying  the  methodology,  four  new 
failure  situations  have  been  pointed  out. 
Indeed,  for  example,  it  is  not  usually 
considered  the  possibility  in  which  the 
called  functionality  doesn't  produce  any 
output . 

More  precisely,  it  has  been  verified  that 
the  output  generated  by  the  first 
functionality,  that  tests  the  presence  of 
new  data  from  the  Front  Panel  Interface, 
cannot  affect  the  final  output,  and  it 
always  exits  when  the  functionality  has  been 
called. 

With  regard  to  the  last  two  functionalities, 
it  exists  the  non  anticipated  possibility  in 
which  the  output  isn't  produced  or  is 
produced  with  an  unexpected  value.  The 
methodology  application  has  furnished  the 
possibility  to  prevent  this  failure 
situation,  by  introducing  the  opportune 
fault'tolerance  mechanisms. 

3.2  CS17s  fiailojDea  AMlyaia 

The  software  design  has  been  made  using  the 
SD  (Structured  Design)  tecnique. 

It  has  been  pointed  out  a  final  output  of 
risk  class  2,  which  is  the  Flight  Safety 
Involved  Signal  identified  during  the 
previous  analysis  phase. 

Shortly,  there  is  a  CSU  to  test  the  presence 
of  new  data  from  the  Front  Panel  Interface; 
there  is  a  CSU  for  the  data  copy  from  a 
memory  part  to  another. 

The  procedure  application  created  APOSF 
Table  as  partially  displayed  in  Figure  9. 

4.  MimmoB 

As  previously  described,  the  methodology 
considers  the  failure  situations  caused  by 
incorrect  elaboration,  synchronization 
errors,  scheduling  errors.  It  permits  to 
obtain  a  complete  analysis  of  the  possible 
failures. 

The  methodology  application  also  at  detailed 
design  level  allows  to  evaluate  the  possible 
failure  situations  dependent  from  the 
project  context  (e.g..  Operative  System, 
Basic  Software,  memory  dimension,  CPU  clock 
rate,  etc.}. 
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So,  the  principal  characteristic  of  the 
methodology  i^*  that,  besides  the  most 
critical  functionalities  and  CSUs,  the 
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functionalities  and  CSUs  which  contain  error 
filters  or  other  fault**tolerance  mechanisms 
are  considered  with  greater  attention.  Only 
these  parts  are  considered,  and  then  the 
software  to  be  studied  carefully  decreases 
in  dimension. 

By  identifying  the  critical  parts,  the 
methodology  allows  to  support  the  project 
choices,  by  developing  procedures  that 
manage  the  errors  and  recover  the  failure 
situations;  and,  it  allows  to  minimize  the 
testing  activities,  by  planning  the 
functional  and  structural  tests  and  the 
relative  covering  requirements;  and,  it 
allows  to  point  out  those  software  parts  on 
which  the  walkthroughs  and  the  inspections 
have  to  be  made. 

So,  the  methodology  allows  to  obtain  a 
quality  product  with  reduced  time  and 
resources  cost. 

The  introduction  of  opportune  fault- 
tolerance  mechanisms  increase  the 
reliability  of  the  software  part,  and  then, 
of  the  whole  system.  The  fault-tolerance 
mechanisms  have  to  be  applied  in  a 
discriminated  manner,  looking  at  the  maximum 
effect  with  the  minimum  alteration  and 
additional  code. 

By  identifying  the  most  critical 
functionalities  and  CSUs,  the  methodology 
reduces  considerably  the  number  of 
functionalities  and  CSUs  to  be  treated  with 
particular  attention,  and  then  represents  a 
useful  means  to  integrate  the  traditional 
methods. 

5.  rtmms  t>w9ELOBwanB 

Sometimes,  in  particularly  big  projects, 
although  the  number  of  functionalities  to  be 


considered  is  considerably  reduced,  the 
Introduced  procedure  requires  a  lot  of  time. 
For  this  reason  and,  in  general,  for  a  good 
application  of  the  methodology,  it  needs  to 
automate  the  methodology  itself. 

In  this  context,  a  weighted  metric  may  be 
created,  basing  on  the  functionalities  and 
CSUs  risk  classes.  This  metric  may  be 
applied  at  the  end  of  the  analysis  and 
detailed  design  phases. 

This  is  the  next  step  to  be  achieved. 

Furthermore,  the  methodology  furnishes  good 
rules  to  identify  the  most  critical  parts  of 
the  software.  To  obtain  a  quality  product, 
it  is  necessary  to  adopt  opportune  fault- 
tolerance  methodologies. 

Afterwards,  it  follows  the  necessity  to 
create  an  expert  system,  which  evaluates  the 
contingent  demand  and  decides  the  fault- 
tolerance  type  to  be  adopted  in  the  actual 
context . 

This  expert  system  may  operate  together  with 
the  previously  hypothetical  weighted  metric. 
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Discussion 


Questioa  C.  BENIAMIN 

How  is  the  methodology  applied?  Do  it  rely  on  inspection  of  the  structural  analysis  and  structural  design  charts? 

Reply 

The  methodology  has  been  applied  on  the  graphs  obtained  with  the  structural  analysis  applicatiao,  during  the  software 
requiretnents  analysis  phase,  and  on  the  graphs  obtained  with  the  HCXX)  application,  during  the  design  phase.  Werae 
developpiiig  a  tool  to  manage  greater  projects  and  to  operate  with  the  rsults  obtained  bom  other  method  applicaiioii  (eg 
CORE). 

(Question  W.  MALA 

What  definition  has  been  used  for  the  vatwos  risk  classes,  eg  class  I.  class  2,  etc? 

Reply 

The  risk  class  defautioo  has  been  derived  bom  RTCA  DO  178A  using  the  risk  class  terms  'catastrophic*,  etc. 

More  precisely,  the  risk  classes  utilized  in  the  paper  are : 

class  1 :  an  error  affecting  the  humai  life  and  the  environment, 
class  2 :  an  error  that  can  produce  situaiian  in  which  the  human 
life  is  not  safeguarded, 

class  3 :  an  error  that  does  not  affect  the  human  life  safety. 


•  • 
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This  paper  highlights  the  technology  recently 
developed  or  under  development  in  the  US  Air 
Force's  Rome  Laboratory  wftware  Engineering 
Technology  Branch.  This  program  is  generic  in 
nature,  focused  around  development  and  support 
of  large,  mission  critical  and  embedded  software 
systems,  and  thus  is  very  relevant  to  the 
development  and  support  of  avionics  systems. 
Further,  when  a  technology  is  pro^amming 
language  sensitive  or  a  demonstration  vehicle 
requires  selection  of  a  specific  language,  the 
programm  language  selected  is  always  Ada. 
Finally,  this  program  has  four  major  thrusts. 

One  thrust  emphasizes  system  definition 
technology  and  is  concerned  with  development 
and  validation  of  requirements  and 
specifications.  A  second  thrust  explores  and 
builds  technology  for  integrated  software  and 
system  engineering  environments,  with 
emphasis  on  tools,  process  support  and 
enforcement,  and  support  to  development  and 
acquisition  managers.  New  explorations  in  this 
area  include  certification  methodologies  and  tools 
for  reusable  software  components,  and  software 
fault-tolerance  (robustness).  A  third  thrust  deals 
with  the  specification,  prediction,  and 
assessment  of  software  quality.  Rome  Lab  has  a 
framework  for  dealing  with  ail  aspects  of 
software  quality  that  has  [voven  itself  in  Japan. 
The  newest  thrust  is  on  softare  engineering  for 
high  performance  computing.  This  unique 
program  is  evaluating  and  d^eloping  generic 
software  methods  ai^  tools  for  using  high 
performance,  massively  parallel  computers  in 
embedded  and  other  mission  critical  applications. 

INTRODUCTION 

Rome  Laboratory,  formerly  Rome  Air 
Development  Center  (RADQ,  is  one  of  the  Air 
Force's  four  super-labs.  It  is  headquartered  at. 
Griffiss  Air  Force  Base,  which  is  adjacent  to  the 
city  of  Rome,  New  York.  For  over  forty  years, 
Rome  Lab  and  its  predecessor  RADC,  have  been 
a  major  force  in  computer  science  and 


technology  in  areas  such  as  processor  and 
nKmbry  technology,  compilers  and 
programming  languages,  data  bases,  operating 
systems,  artincial  intelligence  (AI)  and  decision 
aids,  computer  security,  and  software 
engineering  technology.  Rome  Laboratc^  is  the 
only  Air  Force  Lab  chartered  to  do  "generic" 
computer  technology.  Research  and 
development  products  have  found  their  way  into 
programs  like  the  F-16,  LANTIRN,  PAVE- 
PAWS,  WWMCCS,  MX,  PERSHING,  and 
many  more  too  numerous  to  mention.  The  basic 
premise  is  that  automated  software  tools  that 
support  solid  software  engineering  principles  is 
the  way  to  approach  the  productivity  and  quality 
problems  from  a  technological  perspective.  Bodi 
DoD  and  Air  Force  studies  of  the  “software 
crisis”  cite  concerns  over  burgeoning  demand  for 
software,  lack  of  stability  in  requirements, 
shortages  of  skilled  personnel,  and  high  costs 
for  soi^are  enor  correction. 

The  program  is  focused  on  all  phases  of  the 
system  and  software  life  cycle  from  requirements 
analysis  through  code,  test,  integration,  and  post 
deployment  support  to  fielded  systems.  We  are 
fa^  with  an  ever  diminishing  defense  budget 
and  many  of  the  systems  in  existence  today  will 
be  aroui^  for  some  time  in  the  future. 
Improvements  to  these  systems  to  maintain  a 
strong  defense  will  be  n^ed  and  the  software 
engineering  technology  applied  during  their 
initial  development  must  be  augment^  during 
the  post  deployment  phase  in  order  to  assure 
continued  success  and  mission  compliance.  The 
software  engineering  program  consists  of  the 
following  technology  areas:  System/Software 
Support  &)vironments.  System  Definition 
Technology,  Software  and  System  Quality,  and 
Software  for  High  performance  Computers.The 
allocation  of  the  tot^  software  engineering 
program  to  these  areas  enables  a  ^us  on  high 
payoff  technology  at  key  points  in  the  life  cycle. 
The  extensive  use  of  Air  Force  Materiel 
Command  (AFMC)  operational  test  and 
evaluation  (Beta)  test  sites  coupled  with  a 
Technology  Transition  Plan  with  the  HQ  Air 
Force  Software  Technology  Su{^rt  Center 
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(STSQ  provide  significant  opportunities  to 
assure  program  responsiveness  to  user  needs 
and  technology  transition. 

1.  SYSTEM/SOFTWARE  SUPPORT 

ENVIRONMENTS 

The  objectives  in  this  area  are  to  develop  life 
cycle  support  capabilities  for  software  intensive 
systems,  to  certify  the  reusability  of  software 
components,  develop  advanced  test  techniques 
for  fault  tolerant  software,  and  to  serve  as  the 
transition  vehicle  for  Rome  Laboratory  software 
engineering  products.  Cunent  work  in  the  area 
has  focused  on  an  intemted  software 
engineering  life  cycle  framework  called  the 
Software  Lafe  Cycle  Support  Environment 
(SLCSE)  (see  Figure  1). 


Figure  1 

Software  Life  Cycie  Support 
Environment 
(SLCSE) 

The  SLCSE  allows  a  system  developer  or 
maintainer  to  capture  the  productivity  and  quality 
enhancements  provided  by  today's  Computer 
Aided  Software  Engineering  (CASE)  tools  in  a 
single  environment,  with  a  single  common  user 
interface  and  data  base.  SLCSE  can  be  arbitrarily 
packed  with  tools  to  the  de^ee  the  user  wants.  If 
used  properly  from  the  beginning  of  a 
development,  SLCSE  will  automatically  provide 
all  the  documentation  required  by  EKDD-STD- 


2167A.  System  engineering  capabilities  will  be 
developed  to  augment  the  SLCSE  and  provide 
for  hardware,  firmware,  and  software 
development.  Tools  for  functional 
decomposition  of  system  requirements  into  their 
respective  allocations  will  be  conducted  such  that 
all  system  components  will  be  accounted  for 
along  with  the  automated  production  of  user 
documentation.  The  Environment  supports  a 
multiplicity  of  high  order  languages  including 
Ada,  FORTRAN,  COBOL,  and  JOVIAL.  A 
SLCSE  Project  Management  System  (SPMS) 
enables  program  managers  to  track  software  life 
cycle  process  during  development  and  to 
match  effort  expended  against  the  work 
breakdown  structure  established,  report  on 
milestone  activity,  and  to  conduct  critical  path 
analyses.  An  Ada  Test  and  Verification  System 
(ATVS)  is  a  component  of  the  SLCSE  tool  set 
and  is  available  to  be  applied  during  the 
development  of  and  supjmrt  to  Ada  software 
systems.  SLCSE  has  undergone  beta-testing  in 
the  aerospace  conununity  and  was  called  "the" 
state-of-the-art  environment  by  the  late  Dr 
Howard  Yudkin,  president  and  CEO  of  the 
Software  Productivity  Consortium. 

Enhancements  to  the  SLCSE  resulting  in  an 
improved  framework  are  ongoing  which  will 
si^ificantly  improve  the  common  user  interface 
and  allow  the  database  to  communicate  with 
several  commercially  available  database 
management  systems.  System  engineering 
concepts  are  being  examined  to  determine  the 
best  way  to  incorporate  system  engineering  tools 
and  methods  into  the  environment.  The 
enhancements  also  provide  a  means  to  control 
and  manage  the  process  of  software  development 
and  production  and  will  be  tailorable  to  unique 
organizational  or  mission  needs.  A  distributed 
architecture  will  be  employed  to  enable  remote 
use  of  common  terminals  for  text  processing  and 
message  handling  as  well  as  sophisticated  work 
stations  for  more  complex  and  difficult  software 
tasks. 

The  enhanced  product  called  ProSLCSE  is  being 
funded  by  Rome  Laboratory,  the  Electronic 
Systems  Division,  and  the  Strategic  Defense 
Initiative.  ProSLCSE  provides  a  computer-based 
framework  which  may  be  instantiated  to  create 
an  environment  tailored  to  accommodate  the 
specific  needs  of  a  software  development  or 
support  project.  A  ProSLCSE  environment 
supports  a  total  lifecycle  concept  (i.e.,  concept 
exploration,  demonstration  and  validation,  and 
engineering  and  manufacturing  development).  A 
key  feature  of  the  ProSLCSE  is  the  repository 
that  contains  all  the  accumulated  information  that 
can  be  transitioned  to  the  Post-Deployment 
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Support  lifecycle  phase.  The  ProSLCSE 
Environment  will  be  fully  productized  and 
suji^rted  with  training,  d^mentation,  on-site 
and  on-call  assistance,  and  site  specific 
installation  and  start-up.  (Rome  Laboratory 
Point-of-Contact:  Mr.  James  R.  Milligan, 
RIVC3CB,  GAFB  NY  13441-5700,  Phone: 
(315)  330-2054,  DSN  587-2054) 

Planned  efforts  include  the  development  of  a 
certiHcation  methodology  and  tooU  to  enable 
software  developers  to  determine  a  "level  of 
confidence"  in  candidate  software  components 
identifted  as  having  reuse  potential  whether  these 
components  exist  in  a  library  or  have  been 
applied  in  like  systems.  Levels  of  certification 
L  will  be  based  on  user  needs  analysis  and  the 

destred/required  confidence  level  sought.  (Rome 
Laboratory  Point-of-Contact:  Ms.  Deborah  A 
Cerino,  RL/C3CB,  GAFB  NY  13441-5700, 
Phone:  (315)  330-2054,  DSN  587-2054) 

Another  effort  will  develop  advanced  test 
techniques  for  fault  tolerant  software  systems 
and  will  address  issues  in  software  requirements 
analysis  and  design  for  fault  tolerance  which  can 
be  integrated  with  conventional  fault  detection 
and  fault  isolatioa  techniques  which  have 
traditionally  dealt  with  hardware  base 
approaches.  (Rome  Laboratory  Point-of-Contact: 
Mr.  Roger  J.  Dziegiel,  Jr.,  RUC3CB,  GAFB 
NY  13441-5700,  Phone:  (315)  330-2054,  DSN 
587-2054) 

2.  SYSTEM  DEnNlTlON 
TECHNOLOGY 

Recognizing  that  requirements  errors  are  the 
most  frequent  (over  50%  of  all  enors)  and  more 
expensive  to  correct  the  further  they  percolate 
through  the  system  (up  to  50  times  more 
expensive  to  correct  in  system  integration  than  in 
requirements  analysis),  the  Rome  Laboratory  has 
focused  on  technology  to  catch  those  enors 
during  the  requirements  phase  itself.  The  process 
begins  with  the  elicitation  of  user  requirements 
whereby  the  user  states  operational  i^uirements 
in  terminology  that  the  user  is  familiar  with.  The 
next  step  is  to  translate  those  requirements  into  a 
specification  of  what  is  required  for  the  solution 
or  system  to  be  fielded  and  it  is  up  to  the 
acquisition  agent  to  build  a  system  and  software 
that  is  responsive  to  the  users  needs.  There  are 
many  opportunities  for  requirements  to  be 
misunderstood  or  incorrectly  specifted  since  the 
user  is  typically  not  directly  involved  in  the 
process  after  the  initial  phases  of  the  life  cycle. 
The  Rome  Laboratory  ^gram  in  diis  area  is 
concentrated  on  producing  a  Requirements 
Engineering  Environment  to  enable  end-item 
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users  to  become  involved  in  the  requirements 
process,  to  provide  techniques  for  automated 
code  production,  develop  reusable 
speciiicaticMis,  a^  to  integrate  requirements 
engineering  technology  more  fully  with  the  life 
cycle  {xocess.  The  Rome  Laboratory 
Requirements  Engineering  Environment  (see 
Fi^e  2)  attempts  to  overcome  requirements 
oriented  problems  by  keeping  the  user  involved 
in  the  process  and  by  providing  the  user  with  an 
early,  and  first  hand,  view  of  what  the  final 
product  should  look  and  feel  like. 
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Figure  2 

Requirements  Engineering 
Environment 
(REE) 

During  the  past  ten  years,  Rome  Laboratory 
developed  and  demonstrated  tools  to  rapidly 
prototype  the  requirements  for  the  displays, 
functionality,  algorithms,  and  performance  of  a 
C3I  system  and  to  insure  that  all  the  individuals 
involved  in  developing  specifications  for  the 
system  have  a  consistent  set  of  views  on  the 
system.  This  technology  is  being  integrated  into 
a  single  requirements  engineering  workstation 
environment.  The  primary  integration  vehicle 
will  be  the  object  management  system.  It  will 
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Store  all  information  which  is  not  in  the  exclusive 
domains  of  the  individual  tools,  thereby  allowing 
sharing  of  information  which  is  needed  by  one 
or  more  of  the  other  tools.  The  environment 
supports  the  research  and  development  of 
methods  and  tools  and  the  application  of  their 
application  to  realistic  C3I  system  and 
software  requirements  problems  and  the 
evaluation  of  these  methods  and  tools  in  terms  of 
the  productivity  of  the  processes  involved 
and  quality  of  the  products  they  produce. 

Reusable  C3I  specifications  are  being 
addressed  to  examine  their  potential  for  post 
deployment  block  upgrades  and  application  to 
other  systems.  Instead  of  code  reusability 
(which  may  not  meet  performance  requirements) 
the  specifications  for  similar  systems  may  be 
decomposed  and  assessed  for  reusability  of 
specifications  which  have  been  verifted  and 
validated  under  operational  conditions.  (Rome 
Laboratory  Point-of-Q)ntact:  Mr.  William  E. 
Rzepka,  RUC3CB,  GAFB  NY  13441-5700, 
Phone;  (315)  330-2762,  DSN  587-2762) 

In  the  future,  the  emphasis  in  requirements 
engineering  technologies  at  Rome  Laboratory 
will  shift  to  considering  more  formal  approaches 
which  take  advantage  of  matured  AI  technologies 
such  as  the  Knowledge  Based  Software 
Assistant  (KBSA).  Since  the  early  1980's  Rome 
Laboratory  has  b^n  developing  the  KBSA  as  an 
alternative  software  development  paradigm  in 
which  a  formal  executable  system  specifleation 
evolves  through  the  elicitation  and 
transformation  of  informal  requirements 
expressed  in  representations  familiar  to  the 
application  scientist  or  engineer. 

Planned  work  involves  the  development  of  a 
Advanced  Requirements  Engineering 
Workstation  and  the  integration  of  the  current 
Requirements  Engineering  Environment  with  the 
Process  Oriented  Software  Life  Cycle  Support 
Environment  (ProSLCSE).  In  the  first  effort, 
corporate  knowledge  and  skills  applied  to 
previous  systems  may  be  brought  to  bear  on  new 
problems  and  system  developments.  Domain  and 
community  knowledge  can  be  input  to  the 
requirements  process  to  further  assist  the  user  in 
defining  and  specifying  system  and  software 
requirements.  The  Advanced  Requirements 
Engineering  Workstation  will  make  use  of  both 
conventional  software  engineering  technologies 
and  artificial  intelligence  a{^oaches  to  develop 
an  environment  for  modeling  requirements 
which  supports  multiple  external  views  of  the 
requirements  while  maintaining  a  single 
consistent  internal  representation  system  which 
allows  reasoning  about  the  requirements.  Work 


is  currently  underway  to  develop  the  architectural 
design  for  this  environment.  (Rmne  LaborakHy 
Point-of-Contact:  Mr.  James  L.  Sidoran, 
RL/C3CB,  525  Brooks  Rd.,  GAFB  NY  13441- 
4505,  Phone:  (315)  330-2762,  DSN  587-2762) 

The  REE/ProSLCSE  integratimi  will  provide  a 
means  for  the  specifications  developed  using 
advanced  requirements  engineering  technology 
to  be  directly  input  to  the  process  established  and 
controlled  by  the  ProSLCSE  Environment,  to 
track  requirements  throughout  the  remainder  of 
the  life  cycle,  and  to  provide  complete 
requirements  traceability.  The  integration  will 
m^e  use  of  both  expert  systems  technology  and 
existing  object  oriented  database  technology  to 
determine  and  transfer  the  requirements  from  the 
Requirements  Engineering  Environment  database 
to  the  ProSLCSE  database.  (Rome  Laboratory 
Point-of-Contact;  Ms.  Elizabeth  S.  Kean, 
RUC3CB,  525  Brooks  Rd.,  GAFB  NY  13441- 
4505,  Phone:  (315)  330-2762,  DSN  587-2762) 

3.  SOFTWARE  AND  SYSTEM 

QVAUIY 

The  Software  and  System  Quality  area  provides 
technology  to  specify,  measure,  and  assess  the 
quality  of  the  software  product.  If  the  process  is 
instituted  and  managed  as  desaibed  atove  in  the 
ProSLCSE,  then  the  products  should  be  more 
correct  and  reliable.  The  automated  assessment 
of  product  quality  enables  the  process  to  be 
measured  and  adjusted  accordingly  for  optimum 
use  of  scarce  resources.  A  framework  and  an 
automated  tool  called  the  QUaJity  Evaluation 
System  (QUES)  (see  Figure  3)  has  been 
develops  at  the  Rome  Laboratory  for 
quantitatively  measuring  the  quality  of  virtually 
every  [xoduct  of  the  software  life  cycle,  from  the 
requirements  specification  to  the  delivered 
software  and  documentation.  Nippon  Electric 
Company  has  already  used  the  technology  to 
achieve  a  net  25%  increase  in  productivity  for 
software  development,  and  a  decrease  in  of  51% 
in  first  year  maintenance  costs.  The  Rome 
Laboratory  has  demonstrated  the  feasibility  of 
expert  systems  to  assist  in  the  selection  and 
tailoring  of  these  metrics  in  command  and 
control,  intelligence,  and  space  applications. 
Software  reliability/test  integration  techniques 
have  been  develop^  which  combine  software 
testing  techniques  such  as  path  testing,  symbolic 
execution,  and  mutation  analysis  with  reliability 
assessment.  The  results  of  this  effort  will  take 
the  form  of  a  guidebook.  A  modest  effort  for 
software  quality  meUiodology  enhancements  is 
examining  the  tteoretical  aspects  of  software 
quality  metrics  and  software  quality  effects  for 
advanced  architectures  such  as  parallel  and 
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highly  concunent  processing  effort  to  sdchess 
the  integration  and  exploitation  of  software 
quality  specification  and  assessment 
technoloj^. 
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Figure  3 

Quality  Evaluation  System 
(QUES) 

A  Cooperative  Research  and  Development 
Agreement  ((HtDA)  with  industry  is  a  joint 
venture  to  validate  software  quality  technology, 
to  establish  benchmarks  and  baselines  for 
comparative  analysis,  and  to  transition  automated 
software  quality  technology  from  the  laboratory 
to  the  field.  The  ongoing  and  planned  activities 
by  the  members  of  the  QIDA  called  the 
Software  Quality  Consortium  are  providing  the 
means  for  both  Air  Force  and  industrial  partners 
to  acquire  automated  software  quality 
technology,  validate  this  technology  on  real- 
world  problems,  and  to  transition  software 
quality  tools  and  technolo^  so  that  it  beoimes  a 
part  of  the  process  of  producing  systems.  The 
QUES  tool  is  being  u^  by  the  consortium  to 
evaluate  software  development  products  and 
provide  an  assessment  ajuinst  specified 
software  quality  goals,  ^ome  Laboratory  Point- 
of-Contact:  Mr.  Andrew  J.  Chruscicki, 
RL/C3CB,  GAFB  NY  13441-5700,  Phone: 
(315)  330-4476,  DSN  587-4476) 


4.  JSQrnvAMLFORHIGH 

PERFORMANCE  COMPUTERS 


The  Rome  Laboratory  progi^  in  the  area  of 
Software  Technology  tor  Hi^  Performance 
computing  is  directed  at  the  wveJopment  of 
software  engineering  technoloj^  to  cope  with 
complex  systems  consisting  ofa  mix  of 
sequential  and  highly  parallel  computing 
equipments.  Current  mvestigations  have 
produced  reports  which  describe  shortfalls  in 
software  high  performance  computer 
architectures.  In  addition,  ongoing  work  is 
focused  on  the  development  of  a  Parallel 
Evaluation  and  Experimentation  Platform 
(PEEP)  (see  Figure  4)  which  will  enable 
researchers  and  developers  alike  to  formulate 
new  apjxoaches  to  algorithm  and  software 
production  which  takes  advantage  of  these 
performance  multiplying  computers.  Areas  to  be 
addressed  include  the  impact  of  parallel 
architectures  on  existing  software  design 
processes,  identification  of  parallel  processing 
tools  and  techniques  to  sup^rt  software 
development  for  high  performance  computer 
architectures,  understanding  and  isolation  of 
target  machine  dependencies,  tradeoffs  between 
portability  and  efficiency,  and  the  effect  of 
pro^am  language  selection  on  the  software 
design  process. 

A  Cooperative  Research  and  Development 
Agreement  (CRDA)  in  Parallel  Software 
Engineering  combines  Air  Force  and  industry 
resources  to  solve  key  problems  faced  by  the  use 
of  highly  parallel  com{wters  and  the  software 
that  is  run  on  these  machines,  often  in  a 
heterogeneous  environment  consisting  of  both 
sequential  and  parallel  processors.  The  period 
1995-2000  will  be  characterized  by  distributed 
computing  among  heterogeneous  compniters, 
many  of  which  may  be  high  performance 
computers. 

Planned  work  in  this  area  involves  the 
specification  of  a  virtual  machine  interface  layer 
for  interaction  between  parallel  software  tools 
such  as  those  found  on  the  PEEP  and  candidate 
architectures  that  may  be  selected  for 
implementation.  Portability  will  be  a  key  factor 
in  such  a  machine,  new  programming  models 
will  be  considered,  and  the  machine  wUl  cover  a 
wide  range  of  high  pierformance  compiuters. 
(Rome  Laboratory  Point-of-Contact:  Mr.  Paul 
M.  Engelhart,  R1VC3CB,  GAFB  NY  13441- 
5700,  Phone:  (315)  330-4063,  DSN  587-4063) 
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Figure  4 

Parallel  Evaluation  and 
E;cperimintation  Platform 
(PEEP) 

An  architecture  independent  parallel  design  tool 
is  planned  which  will  provide  a  means  to  design 
heterogeneous  systems  consisting  of  both 
sequential  and  parallel  computing  equipments. 
The  tool  will  extend  current  design  strategies  for 
sequential  tool  building,  develop  utilities  for  aid 
in  design  understanding,  and  will  demonstrate  an 
advant^  human  computer  interface  for  ease  of 
use  and  tool  apfdicability.  (Rome  Laboratory 
Point-of-Contact:  Ms.  Milissa  M.  Benincasa, 
RL/C3CB,  GAFB  NY  13441-5700,  Phone: 
(315)  330-7650,  DSN  587-7650) 

In  future  efforts  software  issues  that  must  be 
addressed  to  realize  the  performance  benefits  of 
high  performance  computing  include  improving 
algorithm  science,  parallel  languages  technology 
and  software  development  environments  to  help 
integrate  computers  of  various  designs. 
Computation  strategies  will  be  neerted  that  can 
work  with  a  variety  of  architectures  (e.g.,  shared 
vs  distributed  memories)  to  c^tain  economy  of 
use  through  algorithm  and  software  reuse,  to 
permit  effective  testing  and  to  make  available 
common  high  level  packages  such  as  fourth- 
generation  languages  which  will  be  graf^ic- 
based,  nonprocedural  and  end-user  oriented. 
(Rome  Laboratory  Point-of-Contact:  Mr.  Joseph 


P.  Cavano,  RIVCJCB,  GAFB  NY  13441-5700. 
Phone;  (315)  330-4063,  DSN  587-4063) 
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Discusskm 

Question  R.  SZYMANSKI 

How  will  you  make  your  current  oiviionmem  development  efforts  more  successful  than  previous  US  Drd)  enviroiunem 
devetopmeat  eCforts? 

Reply 

The  approach  we  are  using  is  to  build  a  framework  for  the  user  interface  and  database  and  allow  project  managers  to 
define  t^-the-shelf  or  their  own  internal  tools  to  be  incorporated  within  SLCSE.  The  key  is  for  tte  data  to  be  maintainfd 
throughout  the  lifecycle.  Where  we  ate  building  specific  tools,  we  are  using  off-the-shelf  tecnology  and  encouraging  the 
devetoppers  to  commercialize  the  tools. 

Question  Dr  GRAND! 

You  addressed  the  m^or  area  of  SW  re-use.  Is  the  focus  of  your  investigatioo  on  code  re-use  or  is  your  approach  more 
general  and  addresses  also  specification  and  design  re-use?  In  this  2nd  case,  what  is  your  strategic  appro^  for 
identifying  le-usabie  specification  and  design? 

Reply 

Each  of  the  areas  addresses  le-use  from  their  perspective.  However,  the  system/software  enviiooments  area  is  looking  at 
re-use  in  general.  They  are  addressing  certification  of  specificatioo,  design,  code.  etc. 

Question  D.  NAIRN 

What  is  the  relationshq)  of  your  work  to  CAIS,  APSE,  european  PCTE  environment  standardization  programs? 

Reply 

The  pro-SLCSE  program  is  atieixling  and  monitoring  all  of  the  standards  activities.  In  particular.  pro-SLCSE  is  CALS 
compliant  and  supports  POSDC.  PCTE  is  closely  monitored. 
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SUMMARY 

The  United  States  Air  Force  (USAF) 
requires  the  use  of  the  Ada  programming 
language  in  the  development  of  new 
weapon  system  software.  Each  Ada 
compilation  system  uses  a  Run-Time 
System  (RTS)  for  executive  services  such 
as  tasking,  memory  management,  and 
system  initialization.  Implementing  and 
using  custom  RTS  services  in  each 
software  development  activity  inhibits 
avionics  software  reuse  and  porubility. 

In  addition,  the  USAF  must  support  many 
Ada  compilers  over  the  operational  life 
of  the  weapon  system.  Finally,  extensive 
testing  and  knowledge  is  required  for 
each  RTS. 

In  1990  the  USAF  began  defining  a 
Common  Ada  Run-Time  System  (CHARTS) 
for  real-time  avionics  applications.  A 
contract  was  awarded  to  Westinghouse 
Electric  Corporation  (WEC)  with 
subcontracts  issued  to  compiler  vendors 
DDC-I,  Inc.  and  Tartan,  Inc.  A 
specification  for  the  CARTS  was 
completed  in  1991  and  coding  of  selected 
CARTS  features  was  undertaken.  The 
specification  defined  common  interfaces 
between  the  application  software  and  the 


RTS,  and  between  the  Ada  compiler  and 
the  RTS.  Incremental  coding  of  the 
CARTS  prototype  is  being  done  by  DDC-I 
for  the  MIPS  R3(X)0  processor,  and  by 
Tartan  for  the  Intel  80960  MC  processor. 
Several  prototypes  have  been  developed 
and  tested.  This  paper  covers  the 
signiOcant  CARTS  features  and  services 
offered  to  avionics  software  engineers. 
The  paper  provides  the  results  of 
performance  testing  of  the  CARTS 
features.  Finally,  this  paper  provides 
information  on  the  appropriate  use  of  the 
CARTS  by  avionics  software  engineers. 

INTRODUCTION 

The  CARTS  effort  seeks  to  address  the 
issue  of  portability  and  maintainability 
raised  by  the  use  of  custom  run-time 
systems  across  different  processors  and 
compilers.  It  further  seeks  to  demon¬ 
strate  the  feasibility  of  a  common  Ada 
run-time  system.  The  CARTS  is  aimed  at 
different  compilers  and  targets.  A 
complete  implementation  of  the  CARTS 
would  allow  for  a  seamless  port  of 
application  software  from  one  target  to 
another,  provided  that  the  application 
utilized  both  non-compiler-speciFic  and 
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non-urget-specific  code  wiih  CARTS 
system  calls. 


The  prime  contractor  on  the  effort  is 
Westinghouse  Electric  Corporation  (WEC) 
and  the  subcontractors  are  DDC-I  inc. 
and  Tartan  Inc.  The  CARTS  is  being 
developed  on  a  VAX/VMS  based  DDC-I 
cross-compiler  for  the  MIPS  R30(X).  and 
on  a  VAX/VMS  based  Tartan  cross- 
compiler  for  the  Intel  80960  MC. 

CARTS  is  meant  to  be  the  center  of  a 
complete  Run-Time  System  (RTS).  The 
RTS  consists  of  the  Common  Ada  Run¬ 
Time  System  (CARTS),  the  Compiler 
Specific  Run-Time  System  (CSRTS),  and 
the  Application  Specific  Run-Time 
System  (ASRTS).  The  CARTS  is  the 
portion  of  the  RTS  where  the  interfaces 
and  implementation  are  common  across 
different  Ada  compilers  for  the  same 
hardware  environment. 

The  Compiler  Specific  Run-Time  System 
(CSRTS)  contains  those  portions  of  the 
RTS  that  may  need  to  vary  from  one  Ada 
compiler  to  another,  but  can  be  common 
across  different  applications  using  the 
same  compiler. 

Ihe  Application  Specific  Run-Time 
System  (ASR1S)  contains  those  portions 
of  the  RTS  that  for  a  given  compiler  and 
CARTS  implementation  may  need  to  vary 
from  one  application  to  another. 

CARTS  is  aimed  primarily  at  the  real¬ 
time  Ada  avionics  community  and  seeks 
to  address  its  needs.  In  so  doing,  CARTS 
builds  upon  the  considerable  work  done 
by  industry  groups  and  by  other 
members  of  the  Ada  community  in  the 
area  of  run-time  systems.  One  of  these 
organizations  is  the  ACM  SIGAda,  Ada 
Run-Time  Environment  Working  Group 
(ARTEWG).  The  ARTEWG  sponsored 
efforts  resulting  in  the  Model  Run-Time 
System  Interface  for  Ada  (MRTSI)  and  the 
Catalog  of  Interface  Features  and  Options 
(CIFO)  documents.  These  two  documents 
form  the  basis  for  a  major  portion  of  the 
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CARTS  Software  Requirements 
Specification  (SRS)  [1].  These  documents, 
however,  were  not  the  only  ones 
researched  for  the  CARTS  SRS. 

Specific  requirements  had  also  been 
identified  and  documented  by  other 
members  of  the  Ada  community:  the 
joint  Integrated  Avionics  Working  Group 
(jlAWG)  proposed  requirements  for  a 
common  Ada  run-time  system;  ExlRA 
(Extensions  Temps  Real  Ada)  defined  an 
interface  which  was  developed  under  the 
auspices  of  Aerospatiale,  the  French 
Government  Aerospace  Agency;  and,  the 
Fourth  international  Workshop  on  Real- 
Time  Ada  Issues  (RTAW4)  reviewed  Draft 
2.0  of  the  Ada  9X  Revision  Requirements 
document.  In  addition  to  this,  input  and 
feedback  on  the  features  that  ought  to  be 
included  in  the  CARTS,  was  solicited 
from  internal  user  and  client 
communities  of  Westinghouse  Electric 
Corporation  (WEC),  the  two 
subcontractors,  and  the  USAF. 

CARTS  IMPLEMENTATION  DETAILS 

As  mentioned  in  the  Summary',  the  CARTS 
Software  Requirements  Specification 
(SRS)  was  completed  in  1991.  However, 
due  to  funding  constraints,  only  a 
portion  of  the  entire  SRS,  represented  by 
the  selected  features,  was  scheduled  for 
the  Design  and  Implementation  of  the 
Prototypes.  The  focus  of  the  effort  was 
directed  to  those  CARTS  features  that 
would  be  the  most  useful,  and  hence  have 
the  greatest  payoffs,  from  the 
perspectives  of  real-time  avionics 
software  engineers.  These  features, 
selected  and  prioritized  by  the  team, 
constitute  the  focus  of  the  discussion  in 
this  paper. 

Portions  of  the  (^RTS  have  been 
implemented  in  three  incremental 
prototypes  as  of  the  writing  of  this 
paper.  Currently,  a  revision  of  the  third 
prototype  is  being  implemented  and 
tested.  The  testing  of  CARTS  is  being 
carried  out  by  the  prime  contractor, 
Westinghouse  Electric  Corporation 
(WEC).  The  testing  falls  into  two 


categories:  CARTS-feature  testing  to 
assure  compliance;  and,  performance 
testing  to  evaluate  efficiency.  CARTS 
will  be  discussed  in  nnore  detail  in  the 
Testing  section  of  the  paper. 

CARTS  FEATURES 

As  indicated  above,  selected  CARTS 
features,  identified  as  being  of  high 
priority,  and  having  been  the  subject  of 
considerable  discussion  and  debate,  were 
proposed  for  implementadon  in  the 
CARTS  prototy  pes.  These  more  salient 
features  are  described  in  the  ensuing 
sections. 

Task  Scheduling 

Task  Scheduling  has  been  identified  as 
the  feature  of  highest  priority  by  the 
application  development  community'.  The 
operations  that  support  this  feature  are 
contained  in  the  package  RTS_Primitives. 
One  of  the  operations  is  procedure 
Suspend_Self  v.  hich  enables  the  calling 
task  to  suspend  itself.  This  procedure 
has  a  parameter  of  type  Suspension_lD. 
The  type  Suspension_lD  is  an  integer 
type  that  is  RTS-defined,  and  it  must 
have  a  minimum  of  254  values.  These 
values  identify  the  reason(s)  for  the 
suspension  of  a  task.  A  second  operation 
is  procedure  Resume_Task.  This 
procedure  causes  the  state  of  the 
"Suspended"  task  to  be  reset.  This 
procedure  has  two  parameters.  One  is  of 
t>  pe  Task_iD  and  the  other  is  of  type 
SuspensionJD.  The  type  Task_lD  will  be 
defined  in  a  later  section.  The  third 
operation  is  procedure  Yield.  This 
procedure  causes  the  task  to  yield  its 
physical  processor  to  a  waiting  task  of 
equal  priority.  These  procedures,  in 
addition  to  those  described  in  the 
following  section,  accomodate  Task 
Scheduling.  Another  feature  contained 
in  package  RTS_Priinitives,  is 
Asynchronous  Transfer  of  Control,  which 
will  be  discussed  in  a  later  section. 

Dynamic  Priorities 


Dy  namic  Priority  refers  to  the  ability  of 
a  task's  priority  to  be  changed 
dynamically.  Dynamic  Priority  is 
extremely  important  in  fault  tolerant 
software.  This  feature  is  also  included 
in  the  package  RTS_Primitives.  The 
ability  to  change  the  priority  of  a  task  is 
provided  by  two  operations  supported  by 
the  procedure  Set_Base_Priority.  One 
Set_Base_Priority  procedure,  with  two 
parameters  ot  types  Task_ID  and 
Sy  stenuPriority,  allows  the  priority  of  a 
single  task,  specified  by  the  Task_lD 
parameter,  to  be  changed.  The  other 
Set_Base_Priority  procedure,  with  a 
single  parameter  of  type  System.Priority, 
seu  the  priority  of  the  calling  task  to  the 
value  of  the  parameter.  Similarly,  the 
ability  to  enquire  about  the  base  priority 
of  a  task  is  provided  by  two  operations 
supported  by  the  function  Base_Priority. 
One  Base_Priority  function,  with  a  single 
parameter  of  type  Task_lD,  returns  the 
base  priority  of  the  task  indicated  by 
that  parameter.  The  other  Base_Priority 
function  returns  the  base  priority  of  the 
calling  task 

Task  identifiers 

Task  Identifiers  have  been  identified  by 
the  authors  ot  Clf  O  and  of  the  Fourth 
International  Workshop  on  Real-Time 
Ada  Issues  (RTAW4)  [2]  as  a  feature  of 
importance.  Task  Identifiers  are  a 
storable  type  used  to  uniquely  identify  a 
specific  task  to  the  RTS.  This 
requirement  is  met  by  the  package 
RTS_Task_lD.  This  package  defines  a 
type  Task_ID  and  some  basic  functions 
on  Task  IDs.  The  function  Same.Task 
checks  whether  the  two  parameters,  of 
type  TasIc_lD,  identify  the  same  task; 
the  function  returns  a  value  of  type 
Boolean.  The  function  Self  returns  the 
Task^lD  of  the  calling  task.  Task 
Identifiers,  as  mentioned  in  an  earlier 
section,  are  used  as  a  building  block  for 
other  operations.  They  are  used  to 
implement  Abort_Tasks,  a  procedure 
contained  in  the  package 
RTS_Task_Stages.  This  procedure  is  the 
only  feature  that  has  been  implemented 
in  that  package.  The  procedure 


implemenu  the  Ada  Abort  statement. 

The  parameter  of  the  procedure  is  a  list 
of  valid  Task_IDs. 

Interrupt  Handling 

Interrupt  handling  is  another  of  the  high 
priority  features.  This  feature  is  also 
contained  in  the  package  RTS.Primitives. 
Ilie  package  contains  support  for  the  use 
of  procedures  as  interrupt  handlers.  The 
types  of  interrupts  supported  are 
specified  here. 

Hardware  Interrupts 

Hardware  interrupts  are  specific  to  a 
physical  processor.  The  characteristics 
of  the  physical  processor  define  the 
behavior  of  a  hardware  interrupt.  The 
hardware  interrupt  handler  procedure 
may  neither  propagate  an  exception,  nor 
cause  a  transfer  of  control  directly  in  the 
interrupted  thread  of  control. 
Furthermore,  it  is  globally  bound  to  the 
corresponding  hardware  interrupt. 

Traps 

Traps  are  internal  signals  which  are  the 
result  of  an  anomalous  execution  state  in 
a  particular  task.  A  trap  may  cause  an 
exception  to  be  raised  in  the 
corresponding  task.  The  binding  of  a 
trap  to  a  trap  handler  procedure  is 
accomplished  by  the  task  executing  the 
Attach_lnterrupt_Handler  routine. 

Virtual  Interrupts 

Virtual  Interrupts  can  be  used  by  one 
task  to  effect  an  Asynchronous  Transfer 
of  Control  within  another,  target,  task.  A 
virtual  interrupt  handler  procedure  is 
associated  with  the  target  task  which 
attaches  the  virtual  interrupt  to  the 
handler  procedure.  This  procedure  is 
executed  when  the  virtual  interrupt  is 
delivered  to  the  target  task  as  the  result 
of  a  call  on  the  Interrupt_Task  operation. 
These  Virtual  Interrupts  are  supported 
by  several  operations,  described  herein. 
The  function  Interrupt_Priority,  which 
returns  the  priority  associated  with  the 


specified  interrupt,  has  a  single 
parameter  of  ty  pe 
Machine_Specifics.Interrupt_ID. 
Attach_lnierrupi_Handler,  binds  a 
handier  procedure  to  the  specified 
interrupt,  and  has  three  parameters  of 
the  following  ty  pes: 
Machine_Specifics.lnterrupt_lD; 

S'y  stem.Priority;  and,  Sy  $tem.Address. 

Ilie  prcxedure  Detach_lnterrupt_Handler 
detaches  the  specified  handier  from  the 
specified  interrupt  and  restores  the 
sy  stem  default  handler.  lnterrupt_Task 
delivers  the  specified  virtual  interrupt 
to  the  specified  task.  A  more  detailed 
discussion  of  interrupt  support  in  CARTS 
is  the  subject  of  another  paper  entitled 
“Real  and  Virtual  Interrupt  Support:  The 
Mapping  Of  A  CARTS  Feature  To  Two 
Different  An  hHet  tures“  [3],  and  is  being 
presented  at  Ada  Europe  '93. 

Clocks  and  Delay  s  1  he  Fourth 
International  Workshop  on  Real-Time 
Ada  Issues  (RTAW4)  [21  identified  a 
requirement  for  a  non-adjustable 
monotonic  clock  which  is  used  for  delay  s 
and  for  periodic  execution.  This 
requirement  is  the  rationale  for  most  of 
the  ^  'kage  R'TS.Clock.  The  function 
Clov  k  returns  a  value  that  is 
monotonically  increasing  over  time.  The 
package  also  contains  operations 
Delay _Self  and  Delay  _Until,  and 
ancillary'  arithmetic  functions. 

Delay_SeIf  is  an  operation  that  allows  the 
calling  task  to  blot  k  itself  until  a  lime  of 
D  *  seconds_per_time  has  elapsed;  it 
takes  a  parameter  of  type  Fine_Time. 
Delay_Untjl  is  a  procedure  that  causes 
the  calling  task  to  be  suspended  until  the 
Clock  has  reached  a  specified  time  T;  it 
takes  a  parameter  of  type  Time.  Finally  , 
the  arithmetic  functions  add  and 
subtract  parameters  of  type  Time  and 
Fine_Time. 

Asynchronous  Entry  Calls 

Asynchronous  Entry  Calls  (AEC),  an 
important  CIFO  requirement  that  has 
been  fastidiously  supported  by  the 
ARTEWG,  was  implemented  in  one  of  the 
earlier  CARTS  Prototypes.  Whereas  the 
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Ada  tasking  model  supports  only 
synchronous  communication  via  entry' 
calls,  the  AEC  supports  asynchronous 
communication  via  entry  calls.  This 
mechanism  allows  the  application 
developer  to  enqueue  an  entry  call  to  a 
task  without  waiting  for  that  task  to 
accept  the  call.  In  the  CARTS,  the 
package  RTS_Asynchronous_Calls 
contains  the  procedure 
CalLAsynchronous  which  has  two 
parameters,  one  of  type 
Agent_Collection_lD,  and  the  other  of 
type  Parameter.Block.  The 
Agent_Collection_lD  t>pe  is  used  to 
identify  the  collection  of  s>  stem 
resources  ailocated  to  execute  the 
asynchronous  entry  call.  These  system 
resources  are  called  Agents.  The 
Parameter_Block  ty  pe  is  used  to 
represent  the  block  of  parameter  data 
that  is  transmitted  by  the  asy  nchronous 
entry  call.  The  collection  of  Agents  is 
created  by  the  function 
New_Agent_Collection  which  has  four 
parameters:  Acceptor,  of  ty  pe  Task_lD; 
E,  of  type  Entry_lndex;  Number,  of  ty  pe 
Positive;  and.  Length  of  ty  pe  Positive. 

The  Task-ID  and  Entry _Index  represent, 
respectively,  the  task  and  entry  calls 
that  Agents  shall  use  to  queue  calls.  The 
first  positive  parameter  refers  to  the 
number  of  Agents  involved,  while  the 
second  positive  parameter  refers  to  the 
size  of  the  Parameer_Block.  A  more 
detailed  discussion  of  the  CARTS  AEC 
support  is  the  subject  of  another  paper 
entitled  "The  Implementation  Of 
Asynchronous  Entry  Calls  On  Two 
Different  Architectures"  (4|,  and  is  being 
presented  at  the  National  Aerospace 
Conference  (NAECON  '9i). 

TESTING 

While  the  primary'  responsibility  for  the 
design  and  implementation  of  the  CARTS 
features  into  the  compilers  was  the 
domain  of  the  compiler  vendors,  DDC-1 
and  Tartan,  the  primary  responsibility' 
for  the  testing  was  the  domain  of 
Westinghouse  Electric  Corporation 
(WEC).  Although  revisions  to  the  third 
and  final  Prototype  are  being 


implemented  as  of  the  writing  of  this 
paper,  some  preliminary  testing  has 
already  been  conducted  on  each  of  the 
two  final  CARTS-compliant  Prototypes, 
for  the  two  target  architectures.  The 
testing  can  be  divided  into  two  categories 
as  mentioned  above.  One  category  is  the 
testing  for  compliance  with  the  CARTS 
SRS,  and  the  other  category  is  the  testing 
to  assess  the  run-time  performance  of  the 
implementation  of  the  CARTS  features. 

CARTS-specific  tests  were  developed  to 
test  compliance  of  the  implementation  of 
the  CARTS  features.  Almost  all  of  the 
CARTS  features  that  have  been 
implemented  in  both  compilers,  have 
been  tested  for  compliance.  This  has 
been  accomplished  by  code  inspection 
and  by  conducting  the  CARTS-feature 
tests. 

The  performance  testing  consists  of  a 
subset  of  the  Joint  Intergrated  Avionics 
Working  Group  (JlAWG),  Performance 
Issues  Working  Group  (PIWG),  and  Ada 
Compiler  Evaluation  Capability  (ACEC) 
benchmarks.  The  performance  testing 
was  done  to  assess  whether  the  use  of  the 
various  CARTS  features  that  were 
implemented  was  accompanied  by  any 
significant  overhead  and  run-time 
degradation.  The  implementation  of 
CARTS  into  the  Tartan  baseline  compiler 
for  the  80960  MC  caused  no  degradation 
in  run-time  performance  of  the 
executable  code.  As  a  matter  of  fact,  the 
Tartan  80960  MC  compiler  showed  the 
same  execution  times  for  all  three 
prototy  pes.  The  DDC-I  compiler,  on  the 
other  hand,  showed  significant 
improvement  in  the  first  two  prototypes. 
The  difference  in  the  execution  speeds 
can  be  attributed  to  other  improvements 
made  in  the  compiler  from  DDC-I. 

In  addition  to  this  type  of  unit  testing, 
WEC  has  developed  a  single  application 
that  takes  advantage  of  several  CARTS 
features,  all  designed  into  the 
application.  A  discussion  of  this 
application  is  presented  herein. 


CARTS  APPUCATION 


An  application,  the 
Distributed_MaiLRouter  (DMR),  has 
been  developed  by  Westinghouse  Hectric 
Corporation  (WEC),  to  demonstrate  the 
various  CARTS  features  which  have  been 
implemented  to  date.  The  following 
discussion  describes  the  application  and 
the  CARTS-specific  support  used  to 
facilitate  its  design  and  implementation. 

Description  of  the  CARTS  Application 

ITie  Distributed_Mail_Router  (DMR)  is  a 
distributed  system  employing  a  mail-box 
mechanism  for  inter-task  communication. 
A  logical  system  view  is  presented  in 
Figure  1.  The  different  application  tasks 
communicate  with  each  other  via  a  mail¬ 


box  scheme  which  is  transparent  to  the 
actual  physical  distribution  of  the 
various  application  tasks.  A  typical 
physical  task  distribution  is  shown  in 
Figure  2.  Although  Figure  2  illustrates 
three  CPUs  per  chassis,  and  three 
chassis,  the  system  is  obviously 
extensible  to  N  CPUs  as  shown  in  Figure 
3.  This  particular  conFiguration  was 
chosen  with  a  view  to  facilitating 
interactive  debugging.  Cooperative 
scheduling  between  the  application  tasks 
is  employed  in  order  to  manage  the  CPU 
resource  on  each  module  of  the  system. 
The  only  exception  to  the  cooperative 
scheduling  scheme  is  the  occurrence  of 
an  interrupt  (either  hardware  or 
virtual). 
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Figure  1.  Logical  View  Of  The  System. 


Figure  2.  Physical  View  Of  The  System. 


When  Ada  '83  is  used  to  realize  a  niail- 
boxing  schente,  mail-boxes  are  typically 
implemented  as  buffer  tasks  associated 
with  event  flags  which  provide  a  means 
for  a  task  to  release  the  processor 
resource  while  it  is  "waiting"  on  an  event 
to  occur,  such  as  the  receipt  of  mail  or  an 
I/O  event.  Our  approach  to  the 
implementation  of  the  mail-boxes  uses 
the  Asynchronous  Entry  Calls  (AEC) 
feature  of  the  CARTS  to  provide  the  same 
functionality  as  an  Ada  '83  approach. 

The  Asynchronous  Entry  Cails  feature  of 
the  CARTS  ailows  the  user  to  designate  an 
entry(s)  as  an  asynchronous  entry  (s).  As 
a  resuit  of  this  action  a  queue  is 
associated  with  the  designated  entry 
which  allows  the  caller  of  the  entry  to 
asynchronously  queue  a  data  structure 
which  contains  all  the  information  the 
accepting  task  requires  to  execute  the 
accept  block  at  some  "later  time". 

In  the  CARTS  implementation,  the 
interface  to  the  Asynchronous  Entry 
Calls  functionality  is  provided  by  the 
package  RTS_Asynchronous_Cails  via 
subprograms  and  two  data  types.  The 
private  type  Agent_Collection_ID,  and 
the  function  New_Agent_Collection,  are 
used  to  allocate  collections  of  memoo% 
which  are  used  for  the  entry  queues  of 
the  asynchronous  entries.  A  call  to  the 
function  New_Agent_Collection  returns  a 
value  of  type  Agent_Collection_ID  which 
is  used  as  a  handle  to  identify  that 
particular  collection  of  memory  in  a  call 
to  the  CalLAsynchronous  procedure. 

The  New_Agent_Collection  function  also 
determines  the  number  of  asynchronous 
entry  calls  that  may  be  queued  at  one 
time,  and  the  size  of  the  parameter  block 
(the  other  data  type  defined  in  the 
package)  which  is  to  be  used  for  passing 
parameters  to  the  accept  statement.  In 
the  DMR  application,  the  number  of 
entries  to  be  queued  represents  the 
number  of  mail  messages  for  that  mail¬ 
box,  and  the  size  of  the  parameter  block 
is  the  size  of  the  actual  message.  Two 
entries  per  task  are  used  as  the  mail¬ 


boxes,  one  being  a  Low_Priority  mail¬ 
box,  and  the  other  being  a  High_Priority' 
mail-box.  The  Virtual  Interrupt  handler 
then  transfers  a  mail-box  message  to  the 
high  or  low  priority  mail-box  using  the 
CalLAsy  nchronous  procedure  of  the 
RTS_Asynchronous_Calls  package.  The 
application  task  manages  its  mail-box 
servicing  scheme  by  utilizing  the 
"accept"  statement,  and  the  "count" 
attribute  for  the  entries  designated  as 
the  mail-boxes  for  that  task. 

The  mail-box  servicing  scheme  is 
implemented  on  top  of  the  cooperative 
scheduling  philosophy.  Each  of  the 
application  tasks  contains  a  main 
processing  loop  which  is  executed  after 
the  initialization  preamble.  The 
algorithm  for  the  main  loop  is  presented 
here. 

if  (High_Priorit>_Mailbox’COUNT >  O)  then 
MAILBO.VJiTATt'S HAVt_HlGH_PRLMAlL; 
elslf  (Lotif_Prioril>.-Mailbox’COUNT  >  0)  then 
MAILBOX_S1  ATL'S  HAVE_LOW_PRl_MAn, 
else  MAIL80X_STATljS  NO.MAIU 
end  if; 
loop 

case  MAlLBOX_STATl.'S  is 
when  NO.MAlL  ■> 
select 

accept  High.Priority .Mailbox  do 
copy-  message  to  local  variable 
end  High  JhlorityJ^ailbox; 
or 

accept  Low  J>rfority_Mailbox  do 
copy  message  to  local  variable 
end  Low  J’riority .Mailbox; 
end  select; 

when  HAVLLLOW.PRLMAa  -> 

Yield;  -  Allow  another  task  to  execute 
accept  Low  J’rlortty  ^lailbox  do 
copy  message  to  local  variable 
end  Low.Priority .Mailbox; 
when  HAVE.H1GH.PR1.MA1L  -> 
accept  High.Priorlty.Mallbox  do 
copy  message  to  local  variable 
end  High.Priority ..Mailbox; 
end  case; 

...  process  mail  message  ... 

If  (HlghJ»riorUy_MaUbox'COUNT  >  0)  then 
MA1LB0X_ST.ATUS  HAVEJ1IGH_PR1.MA1L; 
elsif  (lowJ’riority31allbox'COUNT  >  0)  then 
MAILBOX.STATi;S  HAVE.LOW.reLMAn, 

else 

MAILBOX.STAT15S  NO.MAIL; 
end  if; 

end  loop;  -  Main  processing  loop 


The  invocation  of  the  Yield  procedure  is  a 
dispatching  point  that  causes  the  usk 
which  called  it,  to  be  placed  at  the  end  of 
the  dispatch  chain  for  the  tasks  of  equal 
priority. 

In  addition  to  modeling  distributed 
tasking,  the  system  also  models  a  mode 
switching  application.  In  this  sense,  the 
system  can  be  viewed  as  having  four 
distinct  modes  of  operation,  and  each 
mode  is  composed  of  a  set  of  tasks  that 
implements  the  required  functionality  of 
the  mode.  The  Virtual  Interrupt 
capabilities  discussed  in  this  paper, 
along  with  the  CARTS  RTS_Primitives 
subprograms,  are  used  in  the  system  to 
allow  rapid  Asynchronous  Transfer  of 
Control  (ATC)  between  tasks  in  order  to 
effect  rapid  reconfiguration  of  the 
application  tasks  during  mode  change. 

The  rest  of  this  discussion  is  oriented 
towards  the  interrupt  aspects  of  the 
implementation.  Each  CPU  in  the  system 
has  a  "routing  table"  that  contains  the 
information  required  by  the  mail  routing 
subsystem,  and  the  mode  switching 
subsystem.  Messages  which  are  passed 
between  CPUs  contain  a  header  with 
information  which  distinguish  the 
message  either  as  a  mail-box  message,  or 
as  a  mode  change  message.  Depending  on 
the  type  of  the  message,  additional  fields 
of  the  header  provide  the  parameter  data 
needed  by  the  mail  routing  and  mode 
switching  algorithms.  In  the  case  of  a 
mail-box  message,  a  high  priority 
interrupt  service  task 
(VirtuaLInterrupt,  explained  below) 
receives  the  message  via  an 
Asynchronous  Entry  Call,  and  it 
forwards  it  via  another  Asynchronous 
Entry  Call  to  the  appropriate  task.  If  the 
message  is  a  mode  change,  then  the 
hardware  interrupt  handling  procedure 
calls  the  Virtual  Interrupt  procedure 
associated  with  the  interrupt  service 
task,  and  the  handler  effects  the  mode 
change  for  all  mode-specific  application 
tasks  resident  in  each  CPU  of  the  system. 

Before  going  any  further  with  the  details 
of  the  Virtual  Interrupts,  it  is  necessary 


to  briefly  explain  the  priority  scheme 
used  by  the  system.  The  highest  priority 
is  a  group  of  priorities  called 
the  Hardware.lnierrupt  range.  The  next 
priority  is  a  single  priority  called  the 
r riticaURegion  priority  that  is 
represented  by 
Hardware_lnterrupt'first  - 1. 
immediately  below  the  Critical-Region 
priority  is  another  range  of  priorities 
called  the  VirtuaLlnterrupt  range. 

Below  the  VirtuaLlnterrupt  range  is  the 
Asynchronous_T  ransfer_Of_Control 
trigger  range.  Finally ,  at  the  bottom  is 
the  Application_Task  range.  These  map 
into  the  CARTS  and  Ada9X  priority  levels 
as  follows:  the  Hardware_InteiTupt 
range  is  the  same  as  the 
System.lnteiTupLPriority  range,  and  all 
others  fall  into  the  System.Priority 
range.  The  CriticaLRegion  priority  is 
used  to  implement  mutual  exclusion  in 
the  regions  below  the 
Hardware_lnterrupt  priorities  by  calling 
a  procedure  in  package  RTS_Primitives 
which  elevates  the  caller's  Base_Priority 
to  this  level  and  masks  off  all  hardware 
interrupts.  When  the  critical  region  is 
exited,  the  Base_Priority'  is  returned  to 
its  prior  value  and  the  interrupt  masks 
are  restored  to  their  previous  values.  The 
elaboration  of  each  application  task 
triggers  several  actions:  it  allocates  its 
high  and  low  priority  mail-boxes;  it  fills 
in  the  "routing  table"  with  the  necessary 
configuration  information;  it  sets  up  its 
VirtuaLlnterrupt  handler  procedure; 
and,  it  then  suspends  itself  by  a  call  to 
the  procedure 

RTS_Primitives.Suspend_Self.  The 
VirtuaLlnterrupt  handler  is  the  same 
for  each  application  task.  An  example  of 
this  is  provided  below. 

procedure  Appllcation_Task_VirtuaJ_IH  is 
Mode :  Glci>al_Types.Mode_Type: 

-  Ntodc_t  ...  Mode_4 
begin 

Determine  the  current  mode  via  ibe  appUcation 
task's  Current-Mode  task  Attribute-ID 

Determine  if  the  appUcation  task  should  be  active 
in  the  current  mode  of  operation  by  checking  the 
"routing  table" 

If  (not  Active  in  this  mode)  then 
caU  RTS-Prlmitives.Suspend-Self 
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call  KTS_l’rtmiUve!i.Set_Base_Piiori(y  lo  reset  the 
task's  priority  to  Its  ’'normal’'  value  in  the 
-routing  table* 

eise 

call  8TS_i’riinltives.Set_Base_Prk>rlty  to  reset  the 
task's  priority  to  Its  'normal'  value  in  the 
'routing  table' 
end  If. 

end  Apptk:atlon_Task_Vlrtual_lH  ; 

A  mode  change  is  executed  when  the 
VirtuaLlnterrupt  handler  for  the 
interrupt  service  task  becomes  active. 

procedure  Mode_Cfaange_Vlrlual_lH  is 
begin 

Enter  Crltical_Reglon 

Determine  the  new  mode  by  accessing  the 
CurTent_Mode  task  attribute  of  the  task  to  which 
It  is  bound.  This  was  set  by  the  hardware 
interrupt  handler  procedure  prior  to 
triggering  this  Virtual  Interrupt  handler. 

Set  the  Current_.Mode  task  attribute  of  all  the 
application  tasks  using  the  data  in  the  'routing 
table' 

Fx't  '"r1t!rtl_Reg|on 

Queue  an  Asynchronous  Entty  Call  of  the  interrupt 
service  task  to  acknowledge  the  mode  change  to 
the  other  CPi; 

Give  all  currently  active  appUcatlon  tasks 
-pending"  VircuaUInterrupts  by  calling  the 
RTS_Primltlves.InterTupt.Task  procedure  for  each 
Task_ID  that  is  designated  as  Active  for  the 
previous  mode 

Call  the  RTS_Prtniitives.Resuine_Task  for  each 
Task_lD  designated  in  the  "routing  table"  as 
Active  for  the  new  mode 

Call  the  RTS_Priniitives.SetJBase_Priority 
procedure  for  each  application  task  with  a 
pending  \'irtual_inleriupt.  setting  them  to  the 
Asynchronous.Transfer.Of.Control  trigger  level  In 
order  to  effect  an  Asynchronous  Transfer  of 
Control  to  the  appUcatlon  tasks  as  soon  as  this 
procedure  and  any  pending  hardware  interrupts 
are  complete 

end  Mode_Change_Virtual_IH; 


CONCLUSION 


demonstrated.  These  portions  of  the  SRS 
are  represented  b>  the  features  selected 
as  a  result  of  the  feedback  obuined  from 
a  cross-sec  don  of  the  Ada  community-: 
real-time  embedded  systems  developers; 
client  communities  of  the  compiler 
subcontractors;  and,  the  USAF.  This 
feedback  indicated  a  far  greater  desire 
for  run-dme  systems  to  provide  a  real- 
dme  embedded  system  applicadon 
developer  with  support  for  additional 
run-dme  services  that  could  be  directly 
accessed  by  the  application.  The  focus  of 
the  effort  was  thus  directed  to  those 
CARTS  features  that  would  be  the  most 
useful,  and  hence  have  the  greatest 
payoffs,  from  the  perspectives  of  real- 
dme  avionics  software  engineers.  As  is 
evident,  these  features,  selected  and 
prioritized  by  the  team,  and  providing 
such  support  for  access  to  the  low-level 
features  of  the  run-time  system, 
constituted  the  focus  of  the  CARTS  work 
done  to  date. 

CARTS  is  a  good  baseline  to  assess  the 
concept  of  a  common  Ada  run-time 
system.  Tesdng  clearly  shows  that 
applicadon  software,  that  would 
otherwise  be  compiler-  and/or  target- 
specific  based  on  specific  run-time  calls, 
can  be  ported  across  CARTS-compliant 
compilers/  run-time  systems. 
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The  development  of  the  CARTS  SRS  is  a 
manifestation  of  the  direction  to 
standardize  the  interfaces  for  Ada  RTS's. 
The  inherent  program  constraints,  such 
as  funding  and  schedule,  dictated  that 
only  portions  of  the  endre  SRS,  would  be 
designed,  implemented,  tested,  and 
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Discussion 

Question  W.  MALA 

Will  your  "common  runtime  system"  be  fully  compatible  with  Ada-9X? 

Reply 

Tbe  ctHnmon  runtime  system  has  been  developped  based  on  Ada  83.  How  far  the  "common  runtime  system"  will  be 
compatible  with  Ada-9X  cannot  be  answered  yet,  because  the  definition  of  Ada-9X  has  been  completed  a  few  month 
ago.  Further  investigation  will  be  necessary. 

Question  P.C.  BROWN 

1$  there  any  intention  to  put  the  standard  RTS  forward  as  a  public  domain  standard? 

Reply 

At  this  time,  there  are  no  plans  to  the  Cbmmon  Ada  Runtime  System  as  a  public  standard. 
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Abstract  The  ceitiJication  procedures  apply  to  a  full 
equipment  including  both  hardware  and  software 
components.  The  issue  is  that  the  equipment  supplier  must 
integrate  various  components  coming  from  separate 
sources.  In  particular,  the  Ada  Run  Time  System  is 
embedded  in  the  equipment  as  any  other  application 
component.  This  leads  to  two  major  requirements; 

a.  the  Ada  Run  Time  System  must  be  a  glass  box 

b.  unused  run-time  services  must  be  eliminated  from  the 
embedded  components. 

The  first  requirement  comes  from  the  civil  aviation 
procedures  DO  178A  [  I  ]  and  the  second  is  a  consequence 
of  the  need  to  proof  the  system.  This  can  lead  to  eliminate 
some  unpredictible  or  unsafe  Ada  language  features.  The 
criticity  of  the  system  consists  of  three  levels;  critical, 
essential  and  non  essentiaL  The  report  ARINC  613  (from 
the  Airlines  Electronic  Engineering  Committee)  surveys 
the  Ada  language  and  provides  a  list  of  features  not  to  be 
used  in  avionics  embedded  software  at  least  for  the  two 
first  levels. 

Two  solutions  are  proposed; 

1.  The  SMall  Ada  Run  Time  System  (SMART)  which 
meets  such  requirements  for  an  Ada  subset.  This  Run 
Tune  System  does  not  support  tasking,  exception  and 
dynamic  memory  allocation  except  for  global  objects 
or  fixed  size  collections.  We  show  how  calls  to  this 
reduced  Run  Tune  System  can  be  generated  by  the 
standard  Ada  compilation  system. 

2.  The  alternative  Run  Time  System  called  C-SMART 
which  is  an  approach  used  by  Boeing  with  the 
cooperation  of  Al^  for  the  B777  project.  C-SMART 
shams  most  of  the  SMART  fiuictionalities.  Two 
major  differences  exist;  it  requires  a  devoted  Ada 
compilation  system  and  Aisys  provides  the  end-user 
with  the  test  plan  of  C-SMART  which  consists  also 
of  unitary  tests  set. 


1  Introdnction 

Software  now  pervades  almost  every  aspect  of  human 
endeavour.  Our  transport  systems  depend  on  software  for 
both  control  of  veUcles  and  the  infrastructiue.  Our 
financial  systems  depend  on  software  for  the  control  of 
production.  Our  hospitals  depend  on  software  for  dte 


control  of  life-support  systems.  The  use  of  software  has 
grown  over  the  last  decade  with  the  availability  of  low 
cost,  high  performance  hardware.  This  growth  has  been 
almost  surreptitious  and  it  is  only  recently  that  society  has 
realised  that  the  safety  of  many  human  lives  and  much 
property  now  depends  directly  or  indirectly  upon  the 
correcmess  of  software. 

The  major  attraction  of  software  is  its  flexibility.  However 
this  very  flexibility  brings  with  it  a  greatly  increased 
chance  of  error.  There  is  now  a  strong  awareness  that 
positive  measures  are  required  in  order  to  reduce  the  risks 
of  errors  in  what  has  come  to  be  called  Safety  Critkal 
Software. 

There  is  a  consequential  growing  concern  in  all  major 
industrial  nations  regarding  the  legal  obligation  of 
companies  and  their  officers  to  ensure  that  systems  do  not 
violate  safety  requirements.  Thus  an  officer  of  a  company 
might  be  held  personally  liable  for  loss  of  life  or  property 
caused  directly  or  indirectly  by  incorrect  software 
instaUed  m  the  company,  sold  by  the  company,  or 
installed  in  a  product  sold  by  the  company. 

An  extensive  discussion  of  safety  critical  systems  which 
are  usually  also  real-time  control  systems  will  be  found  in 
reference  (2|. 

2  The  Avtonics  Example 

The  avicmics  industry  has  taken  the  lead  in  the 
development  of  safety  critical  systems.  A  modem 
commercial  aeroplane  contains  a  diverse  combination  of 
computers.  These  computers  may  control  non-critical 
functitHis  such  as  the  entertainment  systems  or  cabin 
lights,  or  safety  critical  systems  such  as  engitres,  flaps, 
ailerons,  or  brakes. 

Before  an  aeroplane  can  carry  fare-paying  passengers,  it 
must  undergo  a  thorough  certification  process  to  provide 
an  acceptable  level  of  coniidetKe  that  it  is  safe  to  do  so. 
The  certification  process  starts  early  in  the  development 
of  an  aeroplane.  ConfideiKe  in  the  safety  of  an  aeroplane 
is  built  up  with  the  aeroplane  itself.  Each  component  of 
the  aeroplane  is  assigned  a  criticality  level,  depending  on 
the  effects  its  failure  would  have  on  the  safety  of  the 
passengers.  The  confidence  in  each  component  must 
match  the  adverse  effect  that  the  component  would  have 
should  it  fiul. 
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As  miny  of  the  components  of  an  aeroplane  are  controlled 
by  computer  softwm,  the  safety  of  the  components  is 
critically  dependent  on  the  safety  of  the  embedded 
software.  The  critkal  role  that  software  plays  in  the  safety 
of  an  aeroplane  has  forced  the  development  of  guidelines 
to  help  independent  assessment  of  its  safety. 

The  Radio  Technical  Commission  for  Aeronautics  is  an 
organisation  in  the  United  States  with  representation  from 
Government,  Airline,  Airframe  and  component 
manufocturers.  The  RTCA  published  a  document 
(Number  RTCA/DO-178)  in  January  1982,  called 
"Software  Consideration  in  Airborne  Systems  and 
Equipment  Certification*.  This  document  was  later 
revised  in  co-ordination  with  the  European  Organisation 
for  Civil  Aviation  Electronics  (EUROCAE)  and  was 
published  as  DO-178A  in  March  198S.  A  further  revision, 
00-178B,  is  expected  to  be  published  in  1993.  By  the 
beginning  of  1993,  most  new  software  certification  efforts 
will  be  conducted  under  the  guidelines  of  this  new 
document. 

These  and  other  safety  standards  all  require  or  recommend 
the  use  of  best  practices  in  all  aspects  of  systems 
development.  One  area  which  is  of  key  importance  is  the 
programming  language  used  as  the  basis  of  the  final 
installed  system.  The  standards  specify  the  use  of  a 
language  which  is  well  defined,  has  validated  tools, 
enables  modular  programming,  has  strong  checking 
properties  and  is  clearly  readable. 

The  conclusion  is  inevitable:  of  all  the  widely  available 
languages,  only  Ada  is  an  appropriate  baseline  for  safety 
critical  software. 


of  the  Requirements  document,  the  Design  document,  the 
Software  lest  plan  and  the  Configuration  plan. 

3.2  Software  Vcrilicadon  Fiaa 

The  Software  Verification  plan  describes  how  the 
software  is  shown  to  be  safe.  It  describes  how  the 
evidence  for  the  assessment  is  collected  and  how  it  is 
presented.  The  verification  of  systems  safety  is  done  by 
review,  testing  and  possibly  format  analysis.  The  plan 
must  show  how  confidence  is  built  up  in  the  lower  level 
software  compoi^nts  and  how  the  integration  of  these 
components  satisfies  the  requirements  of  the  system  as  a 
whole.  Although  thorough  testing  is  always  required, 
there  is  some  debate  over  the  use  of  formal  verification 
methods  at  the  source  level. 

Stylised  mathematical  equations  which  express  the  intent 
of  a  program  may  be  mapped  to  source  code.  Tools  which 
perform  mathematical  instructions  can  perform  various 
checks  which  test  the  correciness  of  the  set  of  equations. 
Formal  verifrcation  of  the  source  code  alone  cannot  show 
that  the  software  is  safe. 

Any  tool  used  to  verify  the  safety  of  an  application  is 
subject  to  the  same  level  of  verification  as  the  application 
(if  there  is  no  further  analysis  done  on  the  tool's  ouqiut) 
Demonstrating  the  correcmess  of  a  program  at  the  source 
code  level  does  not  guarantee  that  the  generated  code  and 
the  way  is  operates  on  the  designated  target  processor 
configuration  is  safe. 

4  Testing  for  Safety 


3  The  Software  Development  Process 

All  Certification  Guidelines  stress  the  importance  of  a 
process  based  on  sound  engineering  practice.  The  steps  to 
be  taken  in  the  development  of  the  safety  critical  software 
must  be  well  understood  and  documented  before  the 
software  can  be  certified  for  safety  critical  applications. 
Rather  than  waiting  until  the  software  is  fully  developed 
and  tested,  it  is  wise  to  involve  the  certification  authorities 
in  the  early  planning  stages. 

3.1  Software  Developmeiit  Plan 

To  raise  the  confidence  in  safety  critical  software,  the 
development  stages  used  in  its  production  must  be 
understood.  Software  developed  by  a  software  engineer 
working  alone  does  not  instil  the  confidence  required  to 
flight  certify  a  system.  A  preferred  approach  is  to  use  a 
team  which  follows  a  controlled  software  engineering 
method.  It  is  important  that  the  method  be  used 
consistently  on  the  project. 

One  of  the  first  documents  to  be  produced  is  the  Software 
Development  Plan.  This  plan  must  describe  the 
development  stages  together  with  a  description  of  the 
materials  developed  and  their  acceptance  criteria.  The 
software  development  plan  must  describe  the  production 


Several  kinds  of  testing  strategies  are  required  to  achieve 
confidence  in  a  safety  critical  system.  "Black  Box"  testmg 
checks  that  each  function  generates  the  expected  results 
under  all  conditions  that  the  function  may  experience.  The 
goal  of  these  tests  is  to  check  the  behaviour  of  the 
function  based  on  its  observable  effects.  Each  function 
must  be  tested  with  its  typical  data  values,  and  also  with 
its  data  values  at  the  boundaries  to  check  the  extreme 
conditions  which  may  be  experienced. 

"Glass  Box”  testing  is  a  more  stringent  testing  process.  It 
involves  analysing  the  structure  of  a  function  under  test  to 
ensure  that  all  the  elements  of  the  function  are  required, 
all  the  elements  are  executed,  and  that  all  execution  paths 
in  the  application  are  adequately  covered.  The  tests  must 
ensure  that  the  program  executes  all  conditions,  and  must 
also  ensure  that  all  conditions  work  correctly  when 
evaluated  to  both  true  and  false. 

Multiple  conditions  tests  are  more  difficult  to  formulate. 
They  require  tests  which  set  all  conditions  to  a  known 
state,  and  then  each  individual  condition  is  set  and  reset  to 
ensure  that  setting  and  resetting  individual  conditions 
causes  a  desired  effect.  Programs  may  be  transformed  by 
assigning  a  multiple  condition  expression  to  a  Boolean 
variable.  This  assignment  would  precede  to  conditional 
statement  which  would  simply  test  the  Boolean  variable. 
Such  a  transformation  does  not  reduce  the  testing 
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fei)uiiciiieiil.  Eadt  cooditioo  must  be  toggled  and  the 
le^t  which  it  assigned  to  the  Bootesn  variable  must  be 
checked  against  the  branches  of  the  conditional  statement 
taken. 

The  tests  and  testing  environment  have  to  be  designed  to 
ensure  that  the  tested  software  is  as  close  to  the  final 
configutation  as  possible.  If  the  testing  environment  is 
intrusive,  the  test  results  must  describe  the  differences  that 
can  be  expected  between  the  tested  and  fiiukl  product 

All  the  System  and  Software  Requirements  must  be 
adequately  covered  by  tests.  All  Derived  Requirements, 
which  are  implicit,  must  also  be  adequately  covered  by 
tests.  The  derived  requirements  address  features  like 
initialisation  of  the  stack,  or  set-up  of  heap  addressing 
registers.  To  ensure  that  every  requirement,  and  every 
byte  of  code  is  tested,  a  compliance  matrix  must  be 
produced  which  records  the  relationship  between 
documents,  code,  tests  and  test  results. 

5  Safe  Ada  Programming 

Ada  has  properties  which  make  it  a  natural  choice  for  the 
development  of  safety  critical  systems. 

•  Ada  is  an  ANSI  and  ISO  standard.  It  is  well  defined 
and  stable  and  thus  provides  a  portable  foundation  for 
the  development  of  supporting  tools  and  libraries. 
The  well-established  validation  mechanism  gives 
trust  in  the  general  quality  of  Ada  compilers. 

•  Ada  supports  Object  Oriented  Design.  In  particular 
there  is  strong  support  for  abstraction  and  the  reused 
of  tested  components. 

•  Ada  has  a  legible  style.  This  is  important  for  the 
satisfactory  execution  of  certification  steps  such  as 
peer  review  and  walkthroughs  as  well  as  later 
maintenance. 

•  Ada  has  a  coherent  modular  construction.  Separate 
compilation  facilities  enable  the  application  to  be 
written  as  a  set  of  units,  with  interface  specifications 
and  the  dependencies  on  their  use  clearly  exposed. 
Ada  compilers  enforce  these  dependencies  and 
ensure  that  if  any  interface  specification  is 
recompiled,  then  the  corresponding  unit  that  uses  the 
interface  must  also  be  recompiled.  Generally  this 
enables  the  organised  construction  of  a  program  from 
trusted  components. 

•  Ada  aids  the  detection  of  errors  at  an  early  stage  of 
development.  Strong  typing  facilities  enable  the  user 
to  construction  programs  where  the  way  data  is  used 
depends  on  the  way  it  was  declared.  Properly  used 
this  ensures  that  most  errors  are  detected  statically 
(that  is  by  the  compiler)  and  that  many  remaining 
errors  are  automatically  detected  at  execution. 

•  Low-level  features  are  provided  through  which  the 
basic  elements  of  the  target  hardware  may  be 


accessed  in  a  logical  manner.  The  address 
representation  clause,  enumeration  represmtation 
clause,  and  unchecked  conversions  are  some  of  the 
features  which  enable  the  program  to  be  mapped  to 
the  target  processor  directly. 

•  Control  over  the  visibility  of  types,  operations  and 
data  provides  a  way  of  limiting  the  features  which 
may  be  used  by  any  program  unit.  For  example, 
before  the  generic  functicm 

UNCHECKED.CONVERSION  can  be  used,  it 
must  be  made  visible  by  a  with  clause.  This  exposes 
the  places  that  this  potentially  unsafe  feature  can  be 
used,  and  allows  special  treatment  and  testing  to 
ensure  that  the  safety  of  the  program  as  a  whole  is  not 
compromised. 

Ada  is,  however,  a  general  purpose  language  and  there  are 
a  number  of  Ada  language  features  which  should  not  be 
used  in  safety  critical  systems.  A  safety  critical  program 
must  be  totally  bounded  in  time  and  memory  used.  This 
time  taken  to  execute,  and  the  amount  of  memory  used  by 
each  element  of  the  program  must  be  determined  and 
verified  as  part  of  the  certification  process.  It  is  extremely 
difficult  to  determine  the  bounds  of  certain  Ada  constructs 
as  they  include  call  to  the  run-time  system  which  may 
need  U>  traverse  run-time  data  structures  which  change  as 
the  program  executes. 

Tasking  operations  require  calls  to  run-time  routines 
which  may  scan  various  queues  and  analyse  several  data 
structures  during  the  scheduling  process.  The  time  Uken 
to  perform  these  operations  depends  on  the  state  of  the 
tasking  queues,  which  in  turn  depends  on  the  state  of  the 
tasks  at  any  given  time.  The  time  taken  by  the  task 
operations  cannot  be  determined  unless  all  the  possible 
states  of  the  tasks  can  be  determuKd  at  each  of  these  run¬ 
time  calls.  Writing  a  test  for  each  tasking  operation  under 
each  of  these  combinations  of  task  states  is  formidable. 
The  current  state  of  the  art  precludes  such  testing. 
Dynamic  use  of  tasks  is  thus  not  recommended  in  safety 
critical  systems. 

The  time  and  memory  used  during  the  elaboration  of 
exception  declarations  and  during  the  raising  of  an 
exception  are  predictable.  Finding  an  exception  handler 
once  an  exception  has  been  raised  involves  searching 
through  subprogram  stack  frames,  or  loading  through 
tables  which  hold  exception  handler  addresses.  The  time 
taken  to  locate  the  appropriate  handler  depends  on  the 
dynamic  nesting  of  subprograms.  Testing  for  all  possible 
subprogram  combinations  at  each  point  an  exception  can 
be  raised  presents  a  combinatorial  explosion  of  states,  as 
exceptions  can  be  raised  implicitly  during  program 
execution.  Thus  the  used  of  dynamic  exceptions  is  to  be 
avoided  in  safety  critical  systems. 

Use  of  heap  storage  presents  a  number  of  problems  for 
certification.  Memory  for  data  to  be  placed  on  the  heap 
can  be  claimed  dynamically  and  released  dynamically  as 
well.  The  order  in  which  the  heap  space  is  claimed 
depends  on  the  use  of  the  execution  of  the  allocator.  This 
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calb  >  nm-time  routine  as  and  when  one  is  lequired. 
Storage  is  deallocated,  explicitly  by  the  use  of 
UNCHICKED.DEALLOCATION  or  impliciUy,  when 
an  acGOM  type  goes  out  of  scope.  Ilie  order  of 
deallocation  is  not  necessarily  the  reverse  order  of 
allocation.  This  fiagments  the  firee  space  in  the  heap.  To 
minimise  fiagnientation.  the  nm-time  system  typically 
uses  algorithms  to  fit  requests  for  space  by  searching  for 
space  availability.  Various  algorithms  may  be  used:  first 
fit,  best  fit  and  so  on.  As  these  searches  ate  not 
deterministic,  they  are  not  permitted  in  safety  critical 
systems.  Although  the  heap  could  be  used,  its  use  must  be 
restricted  to  a  predictable  set  of  operations  where  the  time 
and  memory  used  can  be  determined  by  analysis,  and 
verified  by  testing. 


We  have  thus  seen  that  although  Ada  provides  an 
excellent  foundation  for  safety  critical  systems 
nevertheless  certain  features  need  to  be  avoided.  In  order 
to  meet  this  requirement  a  number  of  iafe  subsets  have 
been  defined.  One  such  system  and  its  supporting  tools  is 
the  SMART  and  C-SMART  systems  developed  by  Alsys. 


6  The  Rim  Time  System 


Ada  programs  implicitly  require  run-time  system  support 
during  a  program's  execution.  The  run-time  system  must 
be  provided  in  the  program  library  which  is  used  during 
the  compilation  of  an  application.  The  application 
developers  have  control  and  visibility  over  their  own 
code,  but  the  Ada  run-time  system  is  usually  not  visible  to 
the  user. 


The  Ada  run-time  system  is  written  to  satisfy  the 
requirements  of  the  Ada  language,  and  the  compiler 
whose  output  it  must  support.  The  design  of  the  run-time 
system  and  the  code  generator  are  inextricably  linked. 


The  run-time  system  is,  of  course,  part  of  the  delivered 
executable  program  and  consequently  for  a  safety  critical 
application  it  must  be  subject  to  the  same  level  of  design 
and  testing  as  the  application  code  itself.  Consequently,  as 
part  of  the  deliverables,  full  documentation  and 
certification  materials  must  be  supplied  not  only  for  the 
application  code  but  also  for  the  run-time  system  actually 
used. 


The  normal  run-time  system  for  full  Ada  is  not 
appropriate  for  a  safety  critical  system  (which  uses  only  a 
subset  of  the  language)  because  it  contains  code  which 
uses  techniques  outside  the  certifiable  regime.  It  is  thus 
necessary  to  provide  a  run-time  system  appropriate  to  the 
level  of  subset  being  used. 


7  SMART  wd  C-SMART  SystcMS 

We  have  thus  seen  that  although  Ada  provides  an 
excellent  foundation  for  safety  critical  systems 
nevertheless  certain  features  tteed  to  be  avoided.  In  order 
to  meet  this  requirement  a  number  of  subsets  have  been 
defined.  Alsys  proposes  two  solutions,  one,  SMART, 
which  can  be  compared  to  a  "Glass  Box*  and  the  second, 
C-SMART,  which  can  be  compared  to  a  "Black  Box*. 

7.1  SMART 

SMART  has  been  designed  to  satisfy  three  general 
requirements: 

•  to  have  the  smallest  run-time  code  possible  in  the 
application 

•  to  enable  the  use  of  a  non-Ada  specific  real-time 
kernel 

•  to  provide  the  basis  of  a  safety  critical  solution 
Minimal  run-time 

SMART  is  a  run-time  executive  that  is  based  on  the 
pritKiple  of  a  "zero  byte  run-time",  hence  its  name  SMall 
Ada  Run  Tune.  It  belongs  to  the  ARTK.  (Alsys  "Ada  Real 
Time  Kernel")  environment,  and  provides  a  possible 
alternative  to  users  who  require  a  small  Ada  run-time. 

The  way  in  which  SMART  achieves  a  minimal  Ada  lun- 
time  is  to  minimise  the  run-time  code  in  addition  to  the 
standard  Alsys  eliminatiuu  of  subprograms  that  are  not 
used  at  link  time.  In  minimising  the  Ada  Run-Time 
System  code,  restrictions  on  the  use  of  the  Ada  language 
ate  introduced.  For  example  exception  handling,  tasking, 
and  input/output  are  not  supported. 

SMART  supports  a  restricted  heap  ntechanism  in  which 
the  services  for  allocating  and  deallocating  objects  are 
redirected  to  two  user-provided  routines  ALLOC  and 
FREE.  No  capability  for  pragma  CONTROLLED  or 
garbage  collector  is  provided.  Though  this  restricted 
model  allows  dynamic  allocation  /  deallocation,  it  is 
mainly  intended  for  static  heap.  A  static  heap  is  a  dynairtic 
memory  area  where  objects  are  allocated  at  run  time  ottly 
once  for  ever  for  the  whole  program  lifetime.  This  heap 
policy  allows  the  declaration  of  unconstrained  types  or  big 
objects  without  restricting  too  much  the  Ada  language 
subset. 

Therefore  the  SMART  approach  corresponds  to  a  Subset 
of  Ada  whose  restrictions  are  as  follows: 

•  Operation  on  discrete  types 

The  attributes  PIMAGE,  and  TVALUE  are  not 
allowed. 

•  Array  types 

Constrained  and  unconstrained  array  types  are 
generally  allowed.  However,  unconstraitied  array 
types  must  be  used  with  caution,  as  memory  may 
be  consumed  by  the  heap  and  never  deallocated. 


•  4 


•  € 


i 
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Bmuim  type  string  is  a  special  case  of 
unconstnined  array  type,  the  restrictions  desoibed 
above  also  apply  to  string. 

•  DiscrtmbttM  conatrabu 

Constrained  and  unconstrained  records  are 
generally  allowed.  However,  as  in  the  case  for 
unconstrained  anay  type,  handling  of 
unconstrained  record  types  can  lead  to  memory 
waste. 

•  AUocators 

Only  objects  of  a  collection  without  a 
'STORAGE_SIZE  clause  or  with  a 
'STORAG£_SIZE  =  0,  can  be  allocated. 
Declarations  of  access  type  on  a  collection  with  a 
'ST0RAGE_S1ZE  clause  are  not  allowed. 

•  Tasks 

Not  supported 

•  Exceptions 

Ada  exception  handling  is  not  supported 

•  Unchecked  Storage  Deallocation 

The  restrictions  on  unchecked  storage  deallocation 
are  those  resulting  from  allocators 

•  Predefined  Language  Attributes 

The  following  attributes  are  not  allowed: 

On  open  types: 

FCOUNT,  ^CALLABLE, 

PTERMINATED 

On  integer  types  or  subtypes:  PTMAGE, 
rVALUE,  PWIDTH 

On  enumeration  types  or  subtypes:  PTOS, 

PWDTH,  PSUCC,  PPRED 

On  fixed  point  types:  PMANTISSA, 

PTARGE,  PTOR 

The  SMART  environment  comes  with  a  standard 
compilation  system  plus  a  specific  option  which  enables 
to  check  that  this  Ada  subset  is  met. 

It  is  interesting  to  note  that  the  Ada  Run  Tone  System 
(ARTS)  subprograms  of  a  SMART  environment  fall  into 
four  classes  of  services : 

1 .  relay  to  user-provided  processing  (dynamic  allocation 
/  deallocaticm  routines). 


2.  *11011  procedures'  (i.e.  begin  null ,  md  ;).  TTus  kind  of 
procedures  are  necessary  because  the  SMART 
envirotsnetkt  comes  with  a  standard  cooapilation 
system  and  stone  optimiaatioos  can  only  be  made  at 
run  time.  In  particular,  those  run-time  optimizations 
that  belong  to  the  Ada  tasking  which  is  not  supported 
in  the  SMART  environmeiU  are  systanatkally 
transformed  into  *null’  procedures.  For  instance  the 
masters  identification  in  certain  situations  of  separate 
compilation  is  detected  at  tun  time,  the  body  of 
cotre^xioding  ARTS  subprograms  is  then  provided 
as  *nidl*  procedures.  These  *null  procedures  *  must 
be  seen  as  bad  optimized  code  rather  than  dead  code 
since  they  are  always  covered  by  the  execution  of  the 
program.  In  the  current  implementation  a  'null 
procedure*  cmisists  of  14  bytes  (for  Motorola  MC 
680x0  processor)  performing  :  a  stack  push  operation, 
a  stack  pop  operation,  and  an  assembly  return 
instruction.  A  maximum  of  six  such  routines  can  be 
embedded  in  an  executable  program.  However  if  the 
separate  compilation  is  not  used  or  if  certain  rules  are 
followed  such  as  not  declaring  separate  units  within  a 
package  body,  then  the  executable  program  will  not 
include  any  *null  procedure*  code  thanks  to  the 
useless  stibprogram  code  elimination. 

3.  subprograms  raising  an  exception  :  Certain  key  words 
are  prohibited,  for  instaiKe  'delay*,  'accept*,  ... 
When  compiling  in  SMART  environment,  warning 
messages  are  issued  by  the  compiler  if  such  key 
words  or  not  supported  Ada  feahires  are  used  in  the 
source  of  the  program.  The  user  must  then  modify  his 
program  before  linking  it.  However  if  be  goes  to  the 
execution  without  modification,  an  exception  will  be 
raised  for  any  of  nnt-supported  feature  which  is 
executed.  It  is  important  to  note  that  if  the  program  is 
compiled  with  no  warning  message  then  the  ARTS 
subprogram  will  not  include  those  ARTS 
subprograms  raising  an  exception,  thanks  to  the 
useless  subprogram  code  elimination  provided  by  the 
staitdard  compilation  system.  This  ensures  that  no 
dead  code  is  embedded. 

4.  Subprograms  to  perform  elementary  arithmetic  and 
logic  operations  (division,  exponentiation,  modulo...): 
These  subprograms  are  not  embedded  if  they  are  not 
called  (because  of  the  useless  subprogram  code 
elimination).  If  they  are  needed  by  the  program  these 
predefined  operations  can  and  must  be  preferably  re¬ 
defined  by  the  user  in  order  not  to  import  the 
predefined  run-time  subprograms  which  might  not 
meet  die  certification  procedures  standards. 

That  way.  under  a  certain  programming  style  the  final 
executable  program  does  not  contain  any  instruction 
beltmging  to  the  Ada  run-time  system  apart  from  the 
necessary  code  to  start  the  program  (e.g.  to  perform  the 
calls  to  the  library  units  elaboration  code).  This  portion  of 
code  is  executed  just  once,  so  the  tests  required  by 
certificatioa  procethires  just  consist  in  proofing  that  this 
portion  of  code  is  covered  with  no  side  effect. 
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To  fiKiiiMe  the  ftmctimel  and  the  Mniciunl  covenfc 
teali  of  the  SMAJIT  Executive  Alsyt  pfovidee  a 
oettiAcelioa  kit  inchiding  sotuce  and  detign  infonnatioa 
about  SMART  code,  allowing  a  *Glass  Box*  approach 
adapted  to  the  ceitificatkM  proceaa. 

7J  C-SMART 

Ihe  Alsya  C-SMART  system  is  a  unilkd  toolset 
enforcing  appropriate  Ada  subset  rules  and  irtcorporating 
a  ccniflable  run-time  system.  It  comprises  two  main  parts: 

•  The  C-SMART  Ada  compiler  is  a  normal  AUys 
compiler  (and  thus  validat^)  but  which  includes  a 
user  option  to  reject  programs  which  use  features  of 
Ada  outside  the  prescribed  deterministic  subset  Any 
construct  whose  worst  case  time  of  execution  and 
q>ace  requirement  cannot  be  predicted  is  thus 
excluded  with  a  warning  message. 

•  The  C-SMART  Executive  which  is  a  specially 
adapted  version  of  Alsys  normal  run-time  system.  (C- 
SMART  is  actually  an  acronym  for  Certifiable  SMall 
Ada  Run  Time  from  which  the  system  gets  its  name). 

The  subset  supported  by  C-SMART  Ada  is  actually 
somewhat  tighter  than  that  outlined  above.  Thus  there  is 
no  tasking  apart  from  the  delay  statement  and  no  user 
exception  handling.  The  only  access  types  allowed  are  at 
the  outer  level,  must  have  constrained  objects  and  static 
coUectitms  (avoiding  deallocation).  Also  a  number  of 
facilities  which  require  the  heap  for  implementation  are 
forbidden.  The  result  is  that  the  run-time  system  is  much 
simpler  than  for  full  Ada. 

The  associated  C-SMART  library  system  ensures  that  all 
the  units  in  a  program  conform  to  the  rules;  the  Alsys 
multilibiary  features  ate  still  available  with  the  additional 
constraint  that  all  sublibraries  must  have  the  C-SMART 
library  as  their  ultimate  parent. 

The  C-SMART  Executive  is,  naturally,  itself  written  in  C- 
SMART  Ada  and  is  certified  and  is  delivered  with  all  the 
documentation  required  as  a  component  of  a  certified 
system. 

The  final  outcome  is  that  the  user  writes  the  safety  critical 
program  in  C-SMART  Ada;  the  linked  program  will  then 
include  the  C-SMART  Executive  (strictly  only  those  parts 
requited  by  that  program).  The  documentation  requited  for 
certification  is  then  comprised  of  that  specific  to  the 
application,  and  developed  by  the  user,  plus  that  part 
relating  to  the  Executive,  and  supplied  by  Alsys. 

The  Alsys  C-SMART  approach  corresponds  to  the  Ada 
subset  which  restrictions  are  as  follows. 

• 


•  i4rTqy  lypes 

Unc^trained  array  types  are  not  allowed. 

•  index  ConstraMs  and  Discrete  Ranges 

The  declatruioo  of  large  array  objects  are  allowed 
only  at  the  global  level. 

•  The  Type  Siring 

Because  the  type  STRING  is  a  special  case  of  one- 
dimensional  arrays,  the  restrictions  describe  above 
apply  as  well  on  STRING. 

•  Record  Types 

Large  record  objects  are  allowed  only  at  the  global 
level. 

•  Discriminants 

Records  with  discriminants  are  said  to  be  large 
records  if  for  certain  values  of  the  discriminants, 
the  record  objects  become  large  objects. 

•  Discriminant  Constraints 

Large  and  constrained  records  are  allowed  only  at 
the  global  level. 

•  Access  Types 

Access  type  definitions  are  allowed  only  at  the 
global  level. 

Access  type  definitions  with  a  'ST0RAGE_S1ZE 
clause  of  0  are  allowed  anywhere. 

•  Aggregates 

Only  static  aggregates  are  allowed. 

•  Logical  Operators  and  Short-circuit  Forms 

The  logical  operations  (OR,  AND,  XOR)  on 
unpacked  arrays  of  boolean  components  are  not 
allowed. 

The  logical  operations  (OR,  AND,  XOR)  are 
allowed  for  PACKed  arrays  of  boolean 
components  whose  size  is  known  at  compiler  time 
and  is  either  8, 16,  or  32  bits. 

•  Binary  Adding  Operators 

The  catenation  operation  (&)  is  not  allowed. 

•  Highest  Precedence  Operators 

The  logical  negation  (NOT)  on  unpacked  arrays  of 
boolean  components  is  not  allowed. 

The  logical  negation  (NOT)  is  allowed  for 
PACKed  arrays  of  boolean  components  whose 
size  is  known  at  compile  time  and  is  either  8,  16, 
or  32  bits. 

•  Allocators 

Only  objects  of  a  global  collection  of  fixed  size 
elements,  with  a  'ST0RAGE_S1ZE  clause  can  be 
allocated  using  an  allocator. 


Operations  on  Discrete  Types 
The  attribute  TTMAGE  is  not  allowed. 
The  attribute  PVALUE  is  not  allowed. 


Task  Specifications  and  Task  Bodies 

Task  specifications  and  task  bodies  are  not 

allowed. 
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•  Tcuk  Types  and  Task  Ob^cU 

Ta»k  types  and  task  objects  are  not  allowed. 
Therefore  the  following  are  not  applicable: 

Task  Execution  -  Task  Activation.  Task 
Dependence  -  Tennination  of  Tasks,  Entries  - 
Entry  Calls  and  Accept  Statements,  Select 
Statements,  Task  and  Entry  Attributes,  Abort 
Statement,  Example  of  Tasking,  Exceptions  Raised 
During  Task  Communication,  Exceptions  and 
Optimisation. 

•  Priorities 

The  pragma  PRIORITY  is  not  supported. 

•  Shared  Variables 

The  pragma  SHARED  is  supported.  Its  only  effect 
is  to  disable  tracking  optimisation  on  the  variables 
being  shared. 

•  Exception  Declarations 

Exception  handlers  are  not  allowed.  As  a 
consequence  any  exception  being  raised  is  fatal.  It 
is  :*'*!  user's  responsibility  to  provide  post-mortem 
pn  jdures  to  catch  any  possible  exception.  Also 
Exceptions  and  Optimisation  are  not  applicable. 

•  Raise  Statements 

Raise  statements  are  not  allowed. 

•  Unchecked  Storage  Deallocation 

The  restrictions  on  unchecked  storage  deallocation 
are  those  resulting  of  the  Allocation. 

•  Input-Output 

No  Input-Output  as  defined  in  the  Reference 
Manual  is  supported  by  C-SMART. 

•  Predefined  Language  Attributes 

The  following  attributes  are  not  allowed. 

FCOUNT,  RIMAGE,  TVALUE, 

PTERMINATED. 

8  Certifled  AppUcadons 

8.1  BSeV  (Braking  and  Steering  Control  Unit)  for 

the  landing  gear  system  of  A330-340  Alrbns 

This  software  has  been  developed  within  Thomson  CSF  t 
D.O.I.  for  Messier  Bugatti,  responsible  for  the  landing 
gear  for  British  Aerospace.  It  has  been  developed  in  less 
than  30  months,  and  has  320  000  lines  of  code,  out  of 
which  140  000  written  in  Ada. 

The  BSCU  calculator  ensures  the  braking  and  anti  skid 
functions  of  the  eight  wheels  and  the  orientation  of  the 
front  wheel-axle  unit  of  all  A330-340  Airbus.  As  for  the 
software,  this  calculator  has  been  entirely  designed  by 
Thomson  CSF  /  D.O.I.  It  comprises  a  redundant 
architecture  with  10  Motorola  microprocessors  (68000, 
68020, 68332)  divided  in  10  numeric  and  analogic  boards. 


The  presentation  was  an  importam  step  towards  the 
certification  of  the  landing  gear  of  A330-340  Airbus.  The 
development  methods  according  to  the  international 
standard  (DO  178A)  guarantees  the  reliability  and  safety 
of  the  system. 

This  software  has  been  successfully  presented  to  the 
European  Cotilication  Authorities  JAA  (Joint  Aviation 
Authorities)  in  September  1992. 

8.2  The  FCDC  Conspater 

The  FCDC  Calculator  (Flight  Control  Data  Coocenfrator) 
is  one  of  the  calculators  used  for  the  electric  flight 
commands  of  A330-340  Airbus. 

Its  functions  are  as  follows: 

to  concentrate  various  information  coining  from  the  other 
electric  fli^t  commands  calculators  and  forward  them  to 
the  information  display  systems  in  the  cockpit,  to  manage 
the  alarms  and  'plane*  maintenance. 

to  analyse  the  behaviour  of  the  other  electric  flight 
commands  calculators,  diagnosis  and  locate  possible 
breakdown  and  store  them  in  order  m  help  the  ground 
nuintenance  teams. 

to  manage  the  dialogue  with  the  maintenance  teams  for 
the  analysis  of  events  occurred  during  the  flight  and  send- 
up  specific  tests  to  the  electric  flight  commands 
ulculators. 

The  criticality  of  some  of  the  above  functions  has  led  the 
Certification  Authorities  to  classify  the  software  of  the 
FCDC  calculator  at  level  2A  (the  reference  documents  for 
all  software  certification  aspects  have  defined  4  criticality 
levels  .1,  2A,  2B  and  3  -  level  1  is  for  software  that  has  to 
meet  a  high  level  of  requirements). 

The  FCDC  calculator  is  based  on  a  Motorola  68000 
microprocessor. 

The  FCDC  Software  is  developed  by  the  Technical 
Division  of  Aerospatiale,  the  FCDC  software  has  a  size  of 
330  Kbyte  for  73,000  lines  of  source  code. 

It  is  composed  of  two  parts: 

•  The  first  part  (65,000  lines)  corresponds  to  the 
fruKtions  of  data  concentration  and  breakdown 
analysis.  It  has  been  given  a  graphic  look  with  a  tool 
named  SAO  set-up  by  Aerospatiale  for  the  design  of 
the  embedded  systems.  The  corresponding  software 
is  automatically  generated  by  a  specialised  software 
developed  for  this  purpose  in  the  Ada  language. 

The  macro-assembler  (compatible  with  the  Alsys  Ada 
compiler)  has  been  used. 

•  The  second  pan  (8,000  lines)  has  been  designed  with 
the  HOOD  method  and  written  in  the  Ada  language. 


It  comspoods  to  the  managenMoi  of  breakdown 
detected  (filing,  string. ...)  and  to  the  dialogtie  with 
the  maintenance  teams. 

The  Alsys  Ada  compiler  as  well  as  SMART  have 
been  used 

The  software  and  the  automatic  generatiim  tools  have 
received  the  agreement  of  the  Certification  Authorities  in 
Deeemher  1992. 

IJ  Hydro-Aire  for  Boeing  777  Brake  Control 
System 

Hydro-Aire  has  selected  Ada  software  development  tools 
for  the  developmrat  of  the  brake  control  system  for  the 
Boeing  777  aircraft.  Hydro-Aire  will  be  using  Alsys 
AdaWorld  cross  compilers  with  the  Alsys  SMART 
Executive  and  Certification  package.  The  certification 
package  will  be  used  by  Boeing  during  FAA  certification 
of  the  brake  control  system  due  to  the  use  of  commercial 
off  the  shelf  (COTS)  software,  specifically,  the  Alsys  run¬ 
time  executive. 

Hydro-Aire  is  using  Alsys  AdaWorld  Ada  compilers  on 
Hewlett-Packard  HP9000/300  platforms,  targeting  the 
new  Motorola  68333  micro  controller.  Each  777  aircraft's 
brake  control  system  will  include  ten  micro  controllers  of 
which  two  are  Motorola  68333  micro  controllers, 
programmed  primarily  in  Ada.  The  Motorola  68333  micro 
controllers  will  control  the  built-in-test  (BITE)  and  Auto 
brake  functions.  The  BfTE  includes  both  an  on-line 
interface  to  the  central  maintenance  computer  and  an  off¬ 
line  maintenance  capability.  The  Auto  brake  automatically 
applies  the  correct  amount  of  brake  pressure  during 
landing,  as  well  applying  the  maximum  amount  of  braking 
during  refused  takeoffs  (RTOs).  The  brake  control  system 
also  includes  additional  hardware  and  software  to 
provided  anti  skid  capabilities. 

9  Coachision 

Alsys  is  currently  and  will  be  even  more  in  the  future 
committed  to  provide  solutions  for  applications  which 
need  to  be  certified. 

The  current  both  maiketing  and  technical  researches  are 
performed  following  two  main  directions: 

•  take  benefit  and  experience  of  the  two  approaches 
SMART  on  68K  and  C-SMART  on  Intel  to 
provide  a  unique  solution  which  offers  the  best  of 
the  two  approaches 

•  investigate  the  possibility  to  extend  the  Ada  subset 
so  as  to  be  used  in  certified  applications;  the 
corresponding  runtime  will  have  to  be  defined 
concurrently. 

The  SMART/C-SMART  solution  will  of  course  allow  the 
two  existing  methods  used  for  certification; 


•  the  ‘glass  box*  approach,  based  on  the  reduction 
of  the  Ada  subset  defined  by  SMART, 


the  *black  box*  approach,  based  on  the  availability 
of  the  complete  package  (i.e.  code  + 
documentation  required  by  the  D0178B  standard) 


The  advantage  of  the  fiinire  unique  solution  will  be  its 
flexibility.  Thanks  to  precise  mapping  between  the 
features  in  the  Ada  subset  aitd  the  corresponding  pieces  of 
code  in  SMART,  a  customer  will  have  the  possibility  to 
use  the  ‘glass  box*  approach  with  a  rather  large  Ada 
subset  (but  limited  to  SMART  subset  anyway)  or  the 
*black  box*  approach  for  a  reduced  Ada  subset. 


The  more  ambitious  solution,  that  is  the  defim'tion  of  an 
Ada  subset  larger  than  the  SMART  Ada  subset,  should 
bring  an  answer  to  the  problem  of  the  increasing 
complexity  of  the  applications  to  be  certified  and  the  even 
bigger  complexity  of  the  certification  process. 


Some  Ada  features  might  not  be  recommended  for  safety 
critical  applications,  because  the  necessary  predictability 
is  not  guaranteed  by  the  language  but  relies  only  on  the 
implementation. 


Current  studies  will  show  which  are  the  ’safe*  features, 
the  features  only  ‘safe’  if  the  implementation  allows  ii 
and  the  *tmsafe”  features  which  are  to  be  avoided  for  a 
safety  critical  application. 


The  purpose  of  the  current  study  is  really  to  identify  the 
second  category  (i.e.  the  features  ‘safe*  because  the 
implementation  is)  because  it  really  depends  on  the  know¬ 
how  and  experience  of  a  major  Ada  vendor  such  as  Alsys. 
This  is  the  main  advantage  since  it  is  complementary  to  an 
only  theoretical  approach,  as  some  tvere  already  used  in 
the  past 
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Discussion 


Question  W.  MALA 

During  tbe  presentation,  Ibe  author  stated  that  the  real-time  executive  could  be  "certified’'  for  use  in  safety  critical 
applications.  I  believe  that  this  position  is  misleading  and  does  not  reflect  the  overall  probtem  of  software  certification  in 
s^ety  critical  applications.  A  Runtime  Executive  on  its  own  can  never  be  "safety  critical"  and  can  therefore  not  be 
certified. 

What  has  been  called  "certification  of  Ada  Real-Ume  execmive"  is  no  mote  than  a  validation  of  the  Real-Time  executive 
against  a  defined  functionality.  Tbe  certification  must  include  the  functionality  and  behaviour  of  all  components 
comprising  tbe  "safety  critical  software  function",  consisting  of  application  software,  Ada  compiler  and  real  time 
executive.  It  would  not  make  sense,  if  the  real  time  executive  would  have  been  certified  and  tbe  Ada  compiler  not. 

Reply 

The  author  accepted  the  comment. 
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Design  of  aTlimwire  ReatTune  Multiprocessor  Operatiiig  System 

Charlea  Gauthier 
Software  Engineering  Laboratory 
Institute  for  Information  Technology 
National  Research  Council  of  Canada 
Ottawa,  Canada,  KlA  0R6 


1.  SUMMARY 

As  more  and  more  capabilities  are  added  to  avionics 
and  other  real-time  or  embedded  systems,  it 
becomes  necessary  to  increase  the  processing 
power  of  the  underlying  executors.  At  any  point, 
technology  imposes  limits  on  the  available 
performance  of  individual  processors.  Increasing 
the  computing  power  beyond  those  limits  requires 
the  use  of  multiple  processors. 

However,  developing  a  multiprocessor  real-time 
system  is  often  difficult  and  expensive.  The  lack  of 
sophisticated  software  tools  iiiakes  the 
development  process  extremely  tedious  and  error 
prone.  In  addition,  many  architectural  difficulties 
must  be  overcome.  Some  real-time  systems  must  be 
implemented  on  top  of  existing  machines  that  do 
not  lend  themselves  well  to  multitasking  systems 
that  depend  on  shared-memory.  Other  real-time 
systems  are  built  from  components  that  present 
particular  architectural  problems.  Data  caches,  in 
particular,  introduce  the  cache  consistency 
problem.  Consistency  protocols  designed  to  keep 
the  caches  consistent  are  not  always  usable,  and 
they  often  introduce  substantial  performance 
penalties.  Without  consistency  protocols,  because 
of  false  sharing,  shared  variables  may  become 
inconsistent  even  if  mutual  exclusion  mechanisms 
are  used. 

This  paper  presents  an  implementation  of  a 
multiprocessor  ra'ltitasking  real-time  operating 
system  on  difficult  architectures.  The  development 
of  applications  on  this  operating  system  does  not 
require  any  special  software  development  tools 
such  as  special  compilers.  Furthermore,  the 
applications  can  be  ported  to  a  very  wide  range  of 
multiprocessor  architectures.  The  principles  of 
operation  of  the  operating  system  can  be  applied  to 
the  implementation  of  an  Ada  runtime 
environment,  if  some  restrictions  are  observed. 

a.  INTRODUCTION 

Developing  a  multiprocessor  real-time  system  is 
generally  more  difficult  and  more  expensive  than 
developing  a  uniprocessor  real-time  system  because 
of  the  added  synchronization  and  communication 
problems.  The  lack  of  specialized  software  tools 
makes  the  development  process  extremely  tedious 
and  error  prone.  Some  programming  languages  do 
provide  multiprocessing  abstractions,  but  they  are 
rarely  used  in  the  development  of  industrial  and 


military  systems.  Most  languages  used  to 
implement  multiprocessor  systems  do  not  support 
the  notion  of  multiple  tasks,  much  lass  multiple 
processors.  Even  Ada,  which  provides  a  tasking 
abstraction,  does  not  support  multiprocessing  at 
the  language  level. 

In  addition,  most  industrial  and  military  real-time 
systems  are  built  from  existing  architectural 
components.  These  components  range  in 
complexity  from  single  microprocessors  to  complete 
multiprocessors,  and  include  board-level  compo¬ 
nents.  Many  of  the  existing  components  present 
serious  obstacles  to  their  use  in  multiprocessors. 
For  example,  most  high-performance  32-bit  and  64- 
bit  microprocessors  feature  on-chip  or  close-coupled 
off-chip  instruction  and  data  caches.  The  use  of 
data  caches  in  shared-memory  or  tightly  coupled 
multiprocessors  introduces  the  cache  coherency  or 
cache  consistency  problem,  which  is  the  problem  of 
insuring  that  ell  processors  operate  upon  the  most 
up-to-date  values  of  variables.  While  many 
processors  provide  hardware  support  for  cache 
consistency,  their  use  with  existing  buses,  such  as 
the  VMEbus,  often  means  that  cache  consistency 
protocols  cannot  be  used.  Without  cache  consis¬ 
tency  protocols,  false  sharing  can  occur.  In  false 
sharing,  variables  that  are  not  shared  at  the 
programming  level  become  shared  at  the  hardware 
level.  False  sharing  means  that  traditional  mutual 
exclusion  mechanisms  no  longer  control  access  to 
shared  data.  As  another  example,  some  existing 
multiprocessors  offer  a  mix  of  shared  and  private 
memory,  complicating  the  implementation  of 
shared-memory  systems  because  data  to  memory 
allocation  must  now  be  controlled. 

The  adoption  of  the  thinwire  model  solves  these 
difficulties.  The  thinwire  model  is  described  in 
detail  in  the  next  section.  Section  4  discusses  in 
detail  the  reasons  one  might  adopt  the  thinwire 
model.  Section  5  then  describes  an  actual 
implementation  of  the  thinwire  model  in  a  shared- 
memory  multiprocessor.  This  implementation  avoids 
the  cache  consistency  problem. 

3.  DEFINITION  OF  THINWIRE 
The  term  thinwire  multiprocessor  is  defined  in  this 
paper  as  a  message-passing  abstract  machine  rather 
than  as  a  physical  machine.  Because  it  is  an 
abstract  machine,  the  underlying  physical  machine 
may  be  a  shared-memory  or  tightly  coupled 
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multiprocessor.  The  characteristics  of  the  thinwire 
abstract  machine  are: 

•  The  thinwire  multiprocessor  is  a  fully 
connected  machine  in  the  sense  that  a 
processor  may  send  a  message  to  any  other 
processor.  A  connection  need  not  be  direct; 
intermediate  nodes  may  exist  in  a  path 
between  two  processors.  However,  routing  of 
messages  through  intermediate  nodes  should 
be  performed  without  the  intervention  of  the 
thinwire  machine;  it  could  be  done  by 
hardware  or  by  layers  of  software  below  the 
thinwire  abstraction. 

•  The  links  in  a  thinwire  multiprocessor  are 
assumed  to  be  reliable  in  the  same  sense  as  a 
backplane  bus  is  assumed  reliable,  i.e. 
messages  are  never  lost  and  are  always 
delivered  in  the  same  order  in  which  they 
were  transmitted.  This  does  not  mean  that 
errors  of  transmission  never  occur,  but  any 
error  in  transmission  is  immediately  signaled 
by  hardware.  Repeated  errors  in  transmission 
indicate  a  system-wide  fault  that  either  causes 
a  system  shutdown  or  requires  the  use  of 
fault-tolerant  techniques  to  mask  the  fault, 
such  as  a  switchover  to  a  backup 
communication  link.  This  assumption  permits 
the  use  of  very  lightweight  protocols  for 
reliable  transmission.  There  is  no  need  for 
heavyweight  protocols  designed  to  deal  with 
lost  messages  or  the  out-of-order  delivery  of 
messages. 

•  Processor  failures  are  considered  system-wide 
faults  that  bring  the  entire  system  down 
unless  fault-tolerant  techniques  are  used  to 
mask  the  faults  or  recover  from  them. 

•  Processors  are  not  autonomous,  i.e.  the  nodes 
are  not  powered  up  and  down  independently 
nor  are  they  reset  independently. 

•  The  thinwire  multiprocessor  runs  a  single 
multiprocessor  operating  system  on  all 
processors.  This  does  not  mean  that  all 
processors  share  a  single  copy  of  the  kernel 
code  or  data  structures.  Given  the  class  of 
machines  the  thinwire  abstract  machine  is 
targeted  to,  it  is  expected  that,  in  most  cases, 
each  processor  would  run  its  own  copy  of  the 
kernel  code  and  would  maintain  its  own  copy 
of  the  global  data  structures.  These  multiple 
copies  of  global  data  structures  are  kept 
synchronized  by  mechanisms  implemented  in 
the  lowest  level  of  the  kernel — on  top  of  the 
message-passing  mechanisms  in  true  message¬ 
passing  machines,  and  in  parallel  or  below  the 
message-passing  mechanisms  in  shared-memory 
machines. 

A  thinwire  system  is  not  a  multicomputer  or  a 
distributed  system.  Both  multicomputers  and 
distributed  systems  are  computer  systems  in  which 


nodes'  run  a  standalone  kernel  and  multiple 
independent  application  programs. 

4.  WHY  BUILD  THINWIRE  SYSTEMS 
As  stated,  the  thinwire  approach  gets  around  some 
architectural  problems  without  resorting  to 
specialized  software  tools.  Some  of  the 
architectural  difficulties  addressed  are: 

•  The  multiprocessor  is  not  a  shared-memory 
machine. 

•  The  multiprocessor  is  built  from  heterogeneous 
processors. 

•  The  multiprocessor  is  a  uniform  shared-memory 
machine,  but  caching  problems  arise  when 
memory  is  shared  arbitrarily. 

•  Ihe  multiprocessor  is  a  uniform  shared-memory 
machine,  but  performance  degradation  occurs 
because  cache  consistency  protocols  are  used. 

These  difficulties  are  discussed  in  detail  in  the 
next  sections. 

4.1  The  multiprocessor  is  not  a  shared- 
memory  machine. 

The  most  obvious  reason,  and  the  most  trivial,  is 
that  the  underlying  machine  does  not  have  shared 
memory.  This  class  of  multiprocessors  includes  true 
message-passing  multiprocessors  like  the 
Transputers  [11(2]  and  the  Message-Driven 
Processor  (3].  It  also  includes  shared-memory 
machines  in  which  only  a  portion  of  local  data 
memory  is  sharable  or  where  complete  connectivity 
does  not  exist  between  the  processors. 

It  is  not  rare  to  find  multiprocessors  in  which  only 
a  portion  of  the  address  space  is  shared.  Such 
machines  are  often  built  to  get  around  a  lack  of 
sufficient  address  bits.  For  example,  with  an  Intel 
8086  processor,  only  20  address  bits  are  available, 
for  a  total  space  of  1  megabyte  of  directly 
addressable  memory.  In  a  multiprocessor  system, 
implementing  a  single,  global  1  megabyte  address 
space  might  leave  insufficient  memory  for  each 
processor  to  store  iis  programs  and  data.  It  is 
preferable  to  give  each  processor  its  own  private 
space  and  to  provide  a  subset  of  the  1  megabyte 
space  as  a  global  memory  space.  In  such  an 
architecture,  it  might  be  preferable  to  treat  the 
multiprocessor  as  a  message-passing  machine  to 
present  the  application  layers  with  a  uniform 
programming  paradigm.  If  the  shared  memory  is 
made  visible  to  the  program,  programmers  or 
compilers  have  to  track  the  sharable  data  and 
allocate  it  to  the  sharable  regions  of  memory. 

Many  single  board  computers  have  only  private 
memory  as  a  cost  reduction  feature.  These  boards 
have  been  designed  specifically  for  applications 
that  require  a  single  general  purpose  processor 
and  rely  on  other  cards  to  provide  I/O  devices  or 
extra  memory.  These  cards  cannot  be  combined  to 
form  a  multiprocessor  unless  global  memory  cards 


'  A  node  in  such  a  system  may  be  a  uniprocessor  or 
a  multiprocessor. 
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•r«  uaad.  In  syatem*  built  from  such  cards,  only  a 
subsot  of  the  memory  is  shared. 

Other  thinwire  candidate  machines  are  the  shared- 
memory  multiprocessors  in  which  the  shared 
modules  are  not  accessible  to  all  processors.  One 
such  machine  is  the  TELDIX  multiprocessor 
developed  by  TELDIX  GmbH  and  used  on  the 
PANAVIA  Tornado  aircraft  [4].  This  architecture  is 
illustrated  in  Figure  1.  Currently,  applications  for 
this  multiprocessor  are  written  in  SD-Scicon  Ada. 
When  building  a  multiprocessor  Ada  application, 
implementors  must  describe  the  underlying 
architecture  of  the  executor  to  an  automated 
application  builder  and  must  specify  the  desired 
processor  access  to  program  units.  An  allocation 
phase  during  compilation  and  linking  attempts  to 
place  these  program  units  in  memory  locations 
accessible  by  the  desired  processors.  If  this  is  not 
possible,  executable  images  are  not  created.  The 
failure  to  transform  the  source  programs  into 
executable  images  is  entirely  attributable  to  the 
support  for  shared  memory;  in  a  thinwire  machine, 
messages  could  be  forwarded  automatically  to  the 
destination  processor. 


Figure  1;  TELDIX  computer  organization 


4.2  The  multiprocessor  is  not  a  homogeneous 
machine. 

It  is  not  rare  in  embedded  systems  to  mix  processor 
types  in  a  single  multiprocessor.  Indeed, 
specialized  processors  such  as  Digital  Signal 
Processors  (DSPs)  may  provide  specialized  services. 
For  example,  in  some  radar  and  sonar  systems, 
DSPs  filter  digitized  echo  data  in  real-time  before 
passing  the  information  on  to  more  conventional 
processors.  Some  DSP  chips,  such  as  the  Motorola 
DSP56000  and  the  members  of  the  Texas 
Instruments  TMS32000  family,  were  designed  to 
communicate  with  other  processors  using  a 
message-passing  scheme  [5][6][7].  One  approach  to 
communicate  with  these  devices  is  to  treat  them  as 
I/O  devices.  This  may  make  sense  with  the  earlier 
devices  such  as  the  TMS32010,  which  has  a 
maximum  of  8k  bytes  of  program  memory  and  288 
bytes  of  data  memory.  However  the  newer  DSPs, 
such  as  the  TMS32040,  have  more  computing 
power  and,  what  is  more  important,  large  address 
spaces.  The  TMS32040  has  a  full  32-bit  data  and 
instruction  address  space  and  6  communication 
links  to  realize  a  variety  of  interconnection 
topologies  [8][9].  This  means  that  it  is  now  feasible 
to  run  multitasking  multiprocessor  operating 
systems  on  these  devices.  In  many  situations,  it 
may  not  make  sense  to  do  otherwise;  the  new 


high-power  DSPs  are  relatively  expenaive,  so  they 
must  be  used  to  their  full  potential.  One  way  to  do 
this  is  to  keep  the  processor  busy  doing  multiple 
signal  processing  functions  or  processing  multiple 
data  streams  in  round-robin  fashion.  It  is  not 
inconceivable  even  to  use  these  processors  in 
priority  driven  systems.  From  a  system  design 
perspective,  it  is  desirable  to  have  a  uniform 
operating  system  running  on  the  overall  system  to 
keep  the  view  of  the  system  simple  and  consistent. 
Given  that  some  manufacturers  do  not  provide 
shared-memory  facilities  to  exchange  data  between 
DSPs  and  between  DSPs  and  other  processors,  a 
thinwire  implementation  is  very  useful.  Other 
considerations  may  also  lead  to  the  adoption  of  a 
thinwire  implementation,  such  as  different  data 
representations  on  the  different  types  of 
processors.  If  the  type  of  the  objects  being 
exchanged  in  messages  was  somehow  known  to  the 
kernel,  data  representation  conversions  could  take 
place  transparently  and  correctly,  which  might  not 
be  the  case  if  the  process  was  left  to  programmers. 

The  previous  discussion  applies  to  a  variety  of 
specialized  processors  used  in  embedded  real-time 
systems,  such  as  graphics  processors. 

43  Caching  problems. 

Caches  have  been  used  successfully  in 
uniprocessors  to  reduce  the  average  access  time  to 
memory  by  keeping  copies  of  data  and  instructions 
in  faster  memory.  In  multiprocessors,  caches  can 
also  be  used  to  reduce  the  need  for  a  processor  to 
fetch  data  from  memory  by  keeping  copies  of  data 
and  instructions  in  the  cache  close  to  the 
processor.  This  not  only  decreases  the  average 
memory  access  latency,  but  also  the  average 
memory  and  communication  contention  [10]. 

Before  presenting  problems  associated  with 
caching,  and  particularly  the  false  sharing 
problem,  which  as  motivated  the  work  reported  in 
this  paper,  a  brief  review  of  cache  organizations 
and  cache  coherency  may  be  of  benefit  to  the 
reader.  An  excellent  survey  on  caching  can  be 
found  in  [11]. 

A  caching  system  breaks  main  memory  into  a 
number  of  usually  equal  size  chunks  called  blocks. 
These  blocks  are  then  copied  individually  into  the 
cache,  into  cache  lines.  Any  reference  to  a  location 
in  a  block  causes  the  entire  block  to  be  copied  into 
a  cache  line,  provided  that  the  block  was  declared 
cacheable.  A  tag,  the  address  of  a  block,  is  stored 
in  a  line  with  every  block  to  distinguish  which 
block  is  in  a  given  line.  Whenever  a  memory  access 
is  made,  the  cache  must  compare  the  block  address 
to  the  tags  in  the  cache.  If  a  matching  tag  is  found 
and  the  block  is  valid,  a  hit  has  occurred, 
otherwise  the  data  is  not  in  the  cache  and  a  miss 
has  occurred. 

During  a  read  from  memory,  if  a  hit  occurs,  the 
data  is  supplied  by  the  cache  and  the  bus  cycle  to 
memory  can  be  preempted,  unless  the  cache 
consistency  protocol  requires  a  memory  cycle. 
During  a  write,  several  possibilities  can  occur 
regarding  the  updating  of  the  caches  and  memory. 
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If  a  hit  occurs,  ths  data  can  be  written  only  to  the 
cache  until  the  data  is  explicitly  flushed  to  memory 
or  until  the  cache  line  is  reused  for  another  block. 
This  mode  of  operation  is  called  copyback  or 
writeback.  An  alternative  is  to  write  the  data  both 
to  the  cache  and  to  memory.  This  is  called 
writethrougk  or  etorethrough.  If  a  miss  occurs,  the 
cache  content  may  be  updated  in  copyback  or 
writethrough  mode,  or  the  data  may  be  written  to 
memory  only. 

The  use  of  data  caches  in  multiprocessors 
introduces  the  cache  coneialency  or  cache  coherency 
problem,  which  is  the  problem  of  keeping  all  the 
cached  copies  the  same.  To  illustrate  the  problem, 
consider  a  two-processor  shared-memory 
multiprocessor.  Assume  processor  A  reads  a 
variable.  The  value  of  that  variable  is  copied  in 
the  cache  of  processor  A.  Now  processor  B  reads 
the  same  variable  and  copies  it  into  its  cache.  If 
processor  A  now  writes  to  the  variable,  processor 
B's  cached  copy  of  that  variable  becomes  obsolete. 
Such  an  out-of-date  value  is  called  a  stale  value. 

Some  caches  can  monitor  bus  traffic  and  take  steps 
to  maintain  consistency.  This  monitoring  is  called 
snooping,  and  the  set  of  rules  followed  to  maintain 
cache  content  consistent  is  called  a  protocol.  For 
example,  an  invalidation-based  protocol  invalidates 
a  cache  line  when  a  cache  detects  a  write  to  a 
memory  block  that  it  has  currently  cached.  If  the 
block  is  referenced  again,  the  up-to-date  value  is 
fetched  from  memory.  An  update-based  protocol 
updates  a  line  rather  than  invalidate  it  as  a  result 
of  snooping.  Some  protocols  require  that  caches 
operate  in  writethrough  mode  so  all  write  cycles 
are  snooped  by  ail  caches.  Other  protocols  require 
that  caches  snoop  read  cycles  to  determine  if  other 
caches  have  copies  of  a  block;  if  so,  to  allow  other 
caches  to  invalidate  or  update  a  block,  a  copyback 
cycle  must  occur  every  time  a  block  held  in  two  or 
more  caches  is  modified. 

The  cache  coherency  schemes  described  so  far 
depend  on  the  existence  of  a  global  bus  to  snoop 
bus  transactions.  Because  of  the  existence  of  buses 
in  all  multiprocessors,  these  schemes  are  the  most 
common  and  possibly  the  only  ones  used  in 
embedded  systems.  Directory -based  caches  also 
exist.  With  these  caches,  the  tags  of  the  various 
caches  are  kept  in  global  directories.  This  means 
that  a  cache  can  determine  if  an  invalidation  or  an 
update  is  necessary;  a  snoop  cycle  is  not  required, 
reducing  contention  for  the  bus.  Directory-based 
caches  are  not  easily  irr.plemented  in  commercial 
bus-based  systems  and  will  not  be  discussed 
further. 

Having  completed  a  brief  review  of  caching, 
problems  it  introduces  can  now  be  examined. 

One  problem  is  that  most  commercial  boards  have 
no  bus  snooping  capability  at  all.  For  example, 
when  a  processor  accesses  its  local  memory,  a  bus 
cycle  is  not  generated  on  the  backplane  bus 
(VMBbus,  NuBus,  etc.).  Hardware  cache 
consistency  is  impossible  in  such  systems  [12][13]. 
For  performance  reasons,  it  is  preferable  to 


generate  snoop  cycles  only  for  shared  data  rather 
than  all  data.  Few  buses  carry  the  necessary 
signals  to  distinguish  the  different  types  of 
accesses.  The  FutureBus  [14]  and  newer 
FutureBus4  (15][161  are  two  exceptions  [17M18], 
but  they  are  still  relatively  unused.  The  current 
bus  systems  fVMEbus,  NuBus,  Multibus  I  and  II), 
which  do  not  support  cache  consistency  well,  are 
not  likely  to  be  abandoned  soon.  Furthermore, 
there  are  many  microprocessors  that  do  not  provide 
hardware-coherent  caches.  The  Motorola  68030 
and  Intel  80486  have  no  built-in  hardware  cache 
consistency  capabilities  at  all^  [19H20),  whereas 
the  68040,  which  supports  both  writethrough  and 
copyback,  must  be  used  in  writethrough  mode  in 
multi-68040  systems  if  hardware  cache  consistency 
is  used  [21]. 

The  solutions  adopted  by  most  implementors  to 
solve  the  cache  consistency  problem  is  either  to 
avoid  it  altogether  by  not  caching  shared  data  or 
by  insuring  that  cached  copies  of  shared  data  do 
not  exist  in  more  than  one  cache  at  any  given 
time.  This  can  be  done  by  serializing  access  to  the 
shared  data  using  any  of  the  available  mutual 
exclusion  mechanisms  and  by  flushing  and 
invalidating  the  cached  global  data  before 
releasing,  the  mutually  exclusive  lock  on  it. 

The  first  solution — not  caching  the  shared  data — 
has  been  used  in  the  IBM  RP3  [22].  However,  it 
has  two  problems.  The  first  is  that  it  can  lead  to 
gross  inefficiencies  because  every  access  to  shared 
data  incurs  the  full  latency  to  memory,  not  to 
mention  that  it  increases  contention  for  memory. 
A  study  by  Owicki  and  Agarwal  confirmed  that  the 
performance  of  this  no-cache  solution  is  worse  than 
any  other  scheme  is  most  cases  and  is  abysmal  if 
there  are  a  large  number  of  references  to  shared 
data  (17%  of  the  instructions  in  the  study){23][24]. 
The  second  problem  is  that  shared  read-write  data 
must  be  identified  and  made  non-cacheable.  This 
process  should  be  done  by  the  compiler  in 
cooperation  with  the  linker  and  runtime  library, 
but  most  commercial  real-time  system  development 
is  done  with  existing  languages  and  development 
systems,  most  of  which,  if  not  all,  do  not  perform 
this  function.  In  many  cases,  each  processor  image 
is  compiled  and  linked  independently,  so  that 
automatic  program  analysis  to  detect  the  sharing 
of  data  is  impossible.  In  almost  all  cases, 
programmers  are  responsible  for  identifying  all 
shared  data  and  placing  it  in  the  appropriate 
locations,  an  exercise  that  is  error  prone. 

The  second  solution — insuring  that  cached  copies 
of  shared  data  do  not  exist  in  more  than  one  cache 
at  any  given  time — is  preferable  from  a 

^  In  fact,  the  Intel  80486  does  provide  inputs  into 
the  cache  so  lines  can  be  invalidated  selectively  by 
external  hardware.  Intel  supplies  an  external 
cache  controller  with  snooping  capability  as  a 
single  VLSI  component,  the  182495.  The  Motorola 
68030  does  not  provide  external  cache  control,  so 
that  hardware  cache  consistency  cannot  be 
implemented. 
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p«rfonnanc«  point  of  view.  Furthermore,  eince  the 
date  ie  chared,  it  ie  likely  to  be  already  protected 
by  come  form  of  mutual  exclusion,  so  nothing 
special  need  be  done.  Unfortunately,  that  solution 
ignores  the  /alee  tkaring  problem  [25].  There  is 
very  little  literature  on  it,  although  it  has  been 
known  to  exist  for  years. 

All  microprocessor  caches  copy  blocks  of  contiguous 
memory  locations  into  the  cache  lines  rather  than 
individual  objects.  The  problem  is  that  cache  lines 
are  totally  unrelated  to  the  software  objects  in 
memory.  This  is  iimsiraied  in  figure  2.  That  figure 
shows  a  portion  of  memory  corresponding  to 
32  bytes  starting  on  a  16-byte  boundary  and 
assumee  a  16-byta  cache  block  size.  If  any  one  byte 
within  one  of  these  blocks  is  referenced  as  part  of 
a  cacheable  memory  cycle,  all  bytes  in  that  block 
are  pulled  into  a  cache  line.  If  the  reference  is  to  a 
multi-byte  entity  that  straddles  two  blocks  (shown 
as  the  shaded  area  in  figure  2),  both  blocks  are 
copied  into  the  cache.  For  example,  a  reference  to 
any  number  of  bytes  in  object  1  causes  the  topmost 
block  to  be  cached,  including  the  first  bytes  of 
object  2.  If  a  reference  is  made  to  the  bytes  in 
object  2  shown  as  the  small  shaded  rectangle,  both 
the  first  and  second  blocks  will  be  copied  into  the 
cache. 


Figure  2:  Relationship  between  program  objects 
and  cache  lines. 

This  scheme  leads  to  the  sharing  of  objects  at  the 
hardware  level,  something  that  is  not  apparent  at 
the  software  level.  To  see  the  problem,  assume 
that  object  1  and  object  2  are  both  protected  by 
some  mutual  exclusion  mechanism  and  that  the 
mechanism  is  properly  used.  Now  assume  that  the 
fragments  of  pseudo-code  shown  in  Figure  3  are 
executed  concurrently. 

The  illustrated  program  is  logically  correct.  Each 
thread  first  gains  exclusive  access  to  the  object 
before  modifying  its  value.  The  locking  mechanism 
can  be  any  of  the  traditional  mutual  exclusion 


mechanisms;  spin  locks,  suspend  locks,  semaphores, 
etc.  1110  object  is  then  flushed  from  the  cache  so  it 
csui  be  accessed  in  memory  by  other  p’ocessors,  and 
the  cached  copy  is  invalidated  before  the  lock  is 
released.  This  insures  that  either  processor  will 
get  the  object  from  memory  and  not  fn>m  its  cache 
the  next  time  it  acquires  the  lock,  in  case  some 
other  processor  has  modified  the  value  in  the 
interval.  Unfortunately,  when  processor  2  caches 
object  2,  it  is  also  caching  object  1.  Similarly,  whan 
processor  1  caches  object  1,  it  is  caching  a  portion 
of  object  2.  One  of  the  two  objects  will  be 
corrupted  in  memory  when  the  flushes  occur; 
object  1  is  corrupted  when  processor  2  flushes  after 
processor  1,  else  object  2  is  corrupted  when 
processor  1  flushes  after  processor  2. 

processor  1  processor  2 

lock(  objectl  );  lock(  object2  ); 

readf  objectl  );  reach  object2  ); 

modify!  objectl  );  modify!  object2  ); 

write!  objectl  );  write!  object2  ); 

flush!  objectl  );  flush(  object2  ); 

unlock!  objectl  );  unlock!  object2  ); 

Figure  3:  Two  logically  correct  threads  that 
illustrate  the  false  sharing  problem. 

There  is  no  way  to  determine  that  false  sharing  is 
occurring  short  of  analyzing  the  memory  layout  of 
program  data.  As  with  the  first  solution,  compilers 
and  linkers  that  control  data  layout  at  this  level 
are  not  readily  available,  so  that  the  process  would 
have  to  be  performed  manually.  This  is  a  highly 
tedious  and  error  prone  process  with  any  non¬ 
trivial  application  program.  If  the  programmers 
have  knowledge  of  the  data  layout  of  the  objects 
and  have  noticed  that  there  is  a  problem,  they 
could  lock  both  object  1  and  object  2  in  a  single 
lock  operation.  This  approach  is  not  a  serious 
option,  because  the  layout  might  change  every 
time  the  program  is  modified.  To  keep  the  program 
as  efiicient  as  possible,  the  locking  code  has  to  be 
changed  every  time  there  is  a  code  change. 
Otherwise,  to  avoid  modifying  the  locking  code,  all 
objects  susceptible  to  being  falsely  shared  together 
have  to  be  locked  together,  thus  seriously 
reducing  performance  by  serializing  access  to  data 
structures  that  otherwise  could  be  accessed 
concurrently.  In  some  machines,  special  access 
instructions  that  do  not  cache  the  accessed  block 
are  available.  However,  they  do  not  solve  the 
problem;  because  of  false  sharing,  an  access  to  a 
cacheable  item  might  bring  into  memory  an  item 
that  is  not  supposed  to  be  cached.  This  item  would 
be  returned  to  memory  whenever  its  containing 
block  was  flushed,  obliterating  the  value  in 
memory,  which  might  have  been  char.g-i. 

In  a  thinwire  system  built  on  top  of  a  shared- 
memory  multiprocessor,  it  is  possible  to  control  the 
size  and  alignment  of  storage  blocks  such  that 
portions  of  two  different  blocks  do  not  lie  in  the 
same  cache  line.  As  long  as  dynamically  created 
objects  are  allocated  in  such  blocks,  they  can  be 


•h*rad  safaly  among  diffarant  procaasora.  It  ia  alao 
poaaibia  to  control  tha  layout  of  atatic  Itarnel  data 
atructuraa,  ao  that  a  thinwira  implamentation  on 
auch  a  machina  could  taka  advantaga  of  tha  shared 
memory  to  achieve  a  high  degree  of  performance. 
What  cannot  be  aharad  are  variablea  declared  in 
the  program  text,  e.g.  global  variables  and  local 
variablea  identified  by  pointers,  because  of  tha 
inability  to  control  the  storage  of  such  objects. 

4.4  Performance  reaaona. 

What  is  not  generally  recognized,  even  though  the 
topic  is  covered  in  standard  textbooks  [26],  is  that 
the  sharing  of  read-write  data  can  also  lead  to 
degradation  of  performance  in  cache  coherent 
systems.  There  are  four  potential  sources  of 
performance  degradation  related  to  the  use  of 
coherent  local  caches; 

1.  Degradation  of  the  average  hit  ratio  due  to 
block  invalidations.  In  systems  that  use  an 
invalidation-based  coherency  protocol,  blocks 
will  have  to  be  fetched  from  memory  repeatedly 
following  invalidations.  Some  of  these 
protocols  also  require  the  use  of  the 
writethrough  memory  update  policy,  a  further 
source  of  performance  degradation. 

2.  Multiple  copyback  cycles  due  to  block 
modifications.  In  systems  that  use  a  copyback- 
based  coherency  protocol,  every  time  a 
processor  modifies  a  block  cached  in  other 
processors,  a  copyback  cycle  is  generated  to 
invalidate  or  update  the  other  copies. 
However,  a  copyback  operation  with  update  in 
the  other  caches  is  more  efficient  than  a 
copyback  operation  with  invalidate  because 
the  modified  block  is  pulled  into  the  other 
caches  during  the  copyback. 

3.  Traffic  between  the  caches  to  detect 
inconsistencies.  In  systems  with  snoopy 
caches,  contention  for  the  bus  can  become  very 
significant  because  all  transactions  to 
cacheable  shared  locations  must  be  broadcast 
to  the  other  caches.  Thus,  the  reduction  in 
bus  contention  obtained  by  keeping  copies  of 
data  close  to  the  processors  is  not  achieved, 
even  for  private  data.  This  has  to  do  with  the 
fact  that  snooping  control  is  generally 
established  at  the  page  level,  as  is  caching 
control,  and  with  the  fact  that  private  data  is 
often  mixed  with  the  shared  data,  so  that 
snooping  cycles  are  generated  even  when  not 
needed. 

4.  Contention  for  access  to  directories.  The 
directories  are  shared  global  resources,  so 
contention  is  unavoidable,  although  some 
clever  directory  designs  may  reduce  it  over  a 
single  ported  non-interleaved  directory.  Such 
a  design  would  also  imply  a  more  sophisticated 
interconnection  network  than  a  shared  bus, 
increasing  the  cost  of  the  system. 

The  first  two  sources  of  performance  degradation 
cannot  be  avoided,  even  if  access  to  and  caching  of 
mutkble  shared  data  is  properly  managed,  because 


of  false  sharing,  i.e.  invalidations  or  updates  can 
result  from  modifications  to  distinct  data  elements 
that  lie  in  the  same  memory  block.  At  best, 
performance  degradation  can  be  reduced  by 
managing  the  true  shared  data.  This  performance 
degradation  due  to  sharing  has  been  studied  by 
Weber  and  Gupta  [27]  and  by  Agarwal  and  Gupta 
[28J. 

The  last  two  sources  of  performance  degradation 
are  built  into  the  coherency  solutions  and  cannot 
be  eliminated.  Worse,  the  performance  degradation 
scales  with  tha  size  of  the  multiprocessor  as  the 
snoop  traffic  increases,  or  as  the  traffic  and 
contention  for  the  directory  increases.  At  some 
point,  hardware  cache  consistency  destroys  any 
benefit  of  increasing  the  number  of  processors.  It 
should  be  possible  to  increase  performance  by 
avoiding  the  cache  consistency  problem  altogether, 
thus  eliminating  the  need  for  coherency  protocols. 
This  is  certainly  true  as  the  number  of  processors 
increases,  especially  with  snoopy  protocols  over  a 
single  shared  bus. 

5.  AN  IMPLEMENTATION 

The  last  section  argued  that  not  all 
multiprocessors  are  shared-memory  machines  or 
homogeneous  machines..  The  last  section  also 
argued  that,  even  in  a  homogeneous  shared- 
memory  multiprocessor,  cache  consistency  protocols 
cannot  always  be  used  and  that,  even  if  they  were 
used,  their  cost  is  often  unacceptable.  That  section 
also  showed  that,  without  cache  consistency 
protocols,  false  sharing  makes  the  usual  mutual 
exclusion  mechanisms  unusable  unless  the  layout 
of  shared  data  is  carefully  controlled.  This  control 
must  be  done  at  the  application  level,  because 
existing  compilers  do  not  do  it.  It  was  shown  that 
these  difficulties  could  be  overcome  by  treating  the 
multiprocessor  as  a  thinwire  machine. 

This  section  looks  at  the  implementation  of  a 
thinwire  abstract  machine  for  a  shared-memory 
homogeneous  multiprocessor.  The  target  system  is 
a  MC68040-ba8ed  multiprocessor  built  from  dual- 
processor  Synergy  SV420  VMEbus  cards.  While 
the  target  system  does  have  shared-memory,  cache 
consistency  protocols  cannot  be  used  to  keep  all 
caches  consistent;  cache  consistency  protocols  can 
synchronize  only  the  data  caches  of  the  two 
processors  on  a  single  card.  The  thinwire  approach 
was  selected  in  this  case  to  avoid  the  cache 
consistency  problem.  Application  programs  are 
prohibited  from  using  shared-memory  for  data 
exchange;  all  data  are  shared  through  message- 
passing.  Memory  is  shared  below  the  application 
level,  i.e.  in  the  kernel.  This  sacrifices  portability 
of  the  kernel  to  non-shared-memory  multipro¬ 
cessors,  but  it  does  achieve  higher  performance. 
The  solution  should  apply  to  any  similar  type  of 
multiprocessor  without  modifications. 

The  implementation  is  integrated  into  the  latest 
release  of  the  Harmony  operating  system 
developed  at  the  National  Research  Council  of 
Canada.  Harmony  is  a  real-time  multitasking 
multiprocessing  operating  system  [29][30]. 


Figure  4;  _TD_Table  data  structure. 


Currently,  versions  of  Harmony  exist  for  the 
Motorola  68000  family  of  processors,  the  Motorola 
88000  family,  and  the  Intel  8086  family.  In  the 
past.  Harmony  was  successfully  ported  to  the 
National  Semiconductor  NS32000  and  the  Digital 
Equipment  Corporation  VAX.  Current  systems 
work  with  the  VMEbus,  Multibus,  and  NuBus. 

Harmony  uses  a  microkernel  and  several  system 
servers  to  provide  services  to  lightweight 
application  tasks.  Harmony  itself  is  written  mostly 
in  C,  with  some  machine-specific  portions  written 
in  assembler.  Applications  running  on  top  of 
Harmony  may  be  written  in  almost  any  language. 
Because  each  processor  image  is  compiled  and 
linked  independently,  special  software 
development  tools  are  not  required. 

To  understand  the  implementation,  is  it  necessary 
to  understand  the  Harmony  message-passing 
primitives.  Harmony  uses  the  send-receive-reply 
mechanism  for  communication  and  synchroniz- 
ation(31][32].  In  this  mechanism,  a  task  that  sends 
a  message  to  another  task  blocks  until  the  task 
sent  to  replies.  A  task  that  receives  a  message 
blocks  until  a  message  is  received^.  A  receiving 
task  can  receive  from  any  task  or  from  a  specific 
task.  The  exact  operation  performed  depends  on 
the  value  of  a  parameter  in  the  receive  function 
call.  The  receiving  task  can  return  data  to  the 
sending  task  in  a  reply  message.  The  reply  call  is 
not  blocking.  The  reply  is  required  to  unblock  the 
sending  task.  A  receiving  task  can  unblock  a 
sending  task  without  sending  any  information 
simply  by  issuing  an  empty  reply  message. 

These  message-passing  primitives  can  be  compared 
to  the  Ada  rendezvous  mechanism  [32].  A  send  is 
analogous  to  an  entry  call.  A  receive  is  analogous 
to  an  accept  of  an  entry.  Both  the  Ada  entry  call 

^  Harmony  also  provides  a  non-blocking  receive.  It 
returns  immediately  if  a  message  cannot  be 
received. 


and  the  accept  are  blocking,  as  are  the  Harmony 
send  and  the  receive.  The  difference  is  in  the 
reply.  In  Ada,  the  reply  is  implicit  and  automatic 
when  the  accepting  task  exits  the  scope  of  the 
accept  statement.  In  Harmony,  the  reply  is  an 
explicit  call  which  can  occur  at  any  point  after  a 
message  was  received  from  the  task  being  replied 
to.  The  possibility  of  issuing  out-of-order  replies 
makes  the  Harmony  message-passing  primitives 
more  flexible  than  Ada’s. 

The  thinwire  implementation  of  Harmony  must 
control  the  content  of  the  caches  when  dealing 
with  shared  data.  Fortunately,  the  only  data  that 
is  shared  between  processors  are  the  messages,  the 
task  control  blocks,  and  a  few  kernel  data 
structures.  All  dynamic  data  structures  are 
allocated  in  memory  blocks  that  are  an  integral 
number  of  cache  lines  in  size  and  aligned  on  cache 
line  boundaries,  thus  preventing  unrelated  objects 
from  lying  in  the  same  cache  lines,  i.e.  avoiding 
false  sharing  problems.  Consequently,  it  is 
sufficient  to  enforce  some  form  of  mutual  exclusion 
on  the  access  to  the  shared  structures,  and  to 
flush  and  invalidate  the  cache  lines  at  the  proper 
points  to  maintain  consistency. 

Because  each  processor  image  is  built 
independently,  the  shared  kernel  data  structures 
are  built  at  system  startup  time  from  information 
in  each  image.  These  structures  are  built  in 
dynamically  allocated  memory  blocks,  so  that  false 
sharing  does  not  occur.  All  but  one  of  the  shared 
kernel  data  structures  are  read-only.  Mutual 
exclusion  is  not  required  for  read-only  shared  data. 
By  building  the  read-only  data  structures  before 
enabling  caching,  cache  consistency  problems  do 
not  arise. 

Only  one  data  structure,  the  _TD_table  illustrated 
in  Figure  4,  is  variable.  This  data  structure  maps 
task  identifiers  (32-bit  integers  assigned  to  tasks 
when  they  are  created)  to  pointers  to  the 
corresponding  task  control  blocks  (TCBs).  As 


shown,  this  data  structure  is  implemented  as  a 
tree.  The  first  level  of  the  tree  is  an  array  with  as 
many  elements  as  there  are  processors  in  the 
system.  This  array  is  created  at  system  startup 
time,  before  caching  is  enabled,  and  is  then  read¬ 
only,  so  that  mutual  exclusion  is  not  required,  and 
caching  this  level  of  the  tree  in  different 
processors  is  not  a  problem.  Each  element  of  this 
array  is  a  pointer  to  a  dynamic  subtree.  One 
subtree  is  allocated  per  processor.  In  the  particular 
implementation  of  the  _TD_tabie  illustrated,  each 
level  of  the  subtree  is  an  array  of  8  elements,  each 
one  indexed  by  a  3-bit  wide  field  in  the  task 
identifier  (task  ID).  The  leaf  nodes  of  each  subtree 
contain  either  a  pointer  to  the  TCB  corresponding 
to  the  task  identifier,  or  an  indication  that  the 
task  identifier  does  not  correspond  to  an  existing 
task.  Only  the  processor  on  which  the  subtree  is 
allocated  updates  the  subtree.  The  update 
procedures  update  the  subtree  branches  atomically 
and  flush  any  changes  from  the  caches,  thus 
insuring  that  the  up-to-date  data  is  in  memory. 
The  procedures  that  read  the  elements  of  the 
subtree  invalidate  the  corresponding  cache  lines  to 
ensure  that  up-to-date  values  are  always  read. 
Again,  because  of  the  atomicity  of  the  updates  and 
the  single  writter,  mutual  exclusion  is  not 
required.  The  flushes  and  invitlidates,  in 
combination  with  control  of  the  data  layout,  are 
sufficient  to  maintain  a  consistent  view  of  this 
structure. 

The  task  control  blocks  are  dynamically  allocated. 
Like  all  dynamically  allocated  data,  the  TCBs  are 
allocated  in  blocks  that  are  an  integral  number  of 
cache  lines  in  size  and  aligned  on  cache  line 
boundaries,  thus  insuring  that  false  sharing  does 
rot  occur.  Any  processor  can  read  and  write  a 
TCB.  An  ownership  protocol  in  used  to  implement 
mutual  exclusion.  For  example,  when  a  task  on 
one  processor  sends  a  message  to  another  task  on  a 
different  processor,  the  ownership  of  the  TCB  of 
the  sending  task  is  transferred  to  the  processor  of 
the  receiving  task  so  that  processor  can  change 
the  state  of  the  sending  task.  The  processor  that 
has  ownership  of  a  TCB  is  the  only  processor  that 
can  modify  it.  This  ownership  protocol  is 
implemented  in  a  state  machine  at  the  core  of  the 
kernel.  Cache  flush  and  invalidate  statements  are 
included  in  the  state  machine  implementation  to 
maintain  caches  consistent.  For  example, 
whenever  a  processor  reads  one  or  more  fields  in  a 
TCB  it  does  not  own,  it  must  invalidate  the 
corresponding  cache  lines  because  the  fields  may 
change.  Without  the  invalidates,  the  reading 
processor  may  read  stale  data. 

The  only  application  level  shared  data  are  the 
messages.  Messages  are  allocated  either 
dynamically  (in  the  heap)  or  as  local  variables  on 
the  stacks  of  tasks.  Messages  allocated  in  the  heap 
are  an  integral  number  of  cache  lines  in  size  and 
aligned  on  cache  line  boundaries.  Consequently, 
false  sharing  cannot  occur,  and  the  blocking 
nature  of  the  message-passing  primitives  provides 
the  required  mutual  exclusion.  When  sending  a 


message,  the  message  is  flushed  from  the  cache. 
When  receiving  a  message,  the  storage  allocated  to 
hold  the  received  message  is  first  invalidated  to 
insure  that  the  actual  sent  message  will  be  read 
from  memory.  These  steps  are  sufficient  to  ensure 
that  dynamically  allocated  messages  are  always 
consistent.  Messages  allocated  on  the  stack  are 
also  dealt  with  properly,  although  understanding 
how  this  is  done  is  more  difficult.  Indeed,  because 
these  messages  are  allocated  by  the  compiler  in  the 
stack  frames,  they  are  not  an  integral  number  of 
cache  lines  in  size  and  they  are  not  aligned  on 
cache  line  boundaries,  so  that  false  sharing  can 
occur.  Fortunately,  Harmony  copies  messages  from 
the  storage  of  one  task  to  the  storage  of  the 
correspondent  task.  Even  in  systems  with  caches, 
only  the  actual  bytes  that  make  up  the  message 
are  copied,  although  complete  blocks  are  pulled 
into  the  caches.  This  copying,  coupled  with  the 
blocking  nature  of  the  message-passing  primitives, 
ensures  that  any  falsely  shared  data  will  not  be 
modified.  Of  course,  all  this  works  only  if  the 
falsely  shared  data  is  not  modified  concurrently. 
Harmony  guarantees  that  there  are  enough  bytes 
placed  on  top  of  a  stack  when  a  task  is  created,  and 
enough  storage  space  left  on  the  stack  for 
exception  processing,  that  any  falsely  shared  data 
must  belong  to  a  blocked  task.  Consequently, 
concurrent  modification  of  the  falsely  shared  data 
cannot  occur. 

The  mechanisms  described  are  sufficient  to 
maintain  a  consistent  view  of  memory  on  a  shared- 
memory  multiprocessor  without  recourse  to  cache 
consistency  protocols.  There  are  no  mechanisms  to 
prevent  application  tasks  from  using  shared- 
memory  for  communication.  However,  the  kernel 
cannot  support  such  usage.  For  example,  pointers 
can  be  passed  in  messages,  but  any  access  through 
such  pointers  is  invisible  to  the  kernel,  so  cache 
consistency  operations  cannot  be  performed 
automatically.  Because  shared-memory  is  not 
supported  at  the  application  level,  the 
multiprocessor  is  described  as  a  thinwire 
multiprocessor. 

6.  CONCLUSION 

The  paper  described  several  problems  that  can 
occur  in  embedded  and  real-time  multiprocessor 
systems.  The  paper  showed  that  these  problems 
can  be  overcome  by  implementing  the  system  as  a 
message-passing  system  rather  than  as  a  shared- 
memory  system.  The  high-performance  type  of 
message-passing  system  proposed  is  described  as  a 
thinwire  multiprocessor.  This  multiprocessor  is  a 
virtual  machine  that  can  be  implemented  on 
shared-memory  machines  with  heterogeneous 
processors  or  without  consistent  caches,  and  on 
non-shared-memory  machines  and  true  message¬ 
passing  hardware. 

An  implementation  of  the  thinwire  multiprocessor 
for  a  shared-memory  machine  without  consistent 
caches  was  described.  The  principles  behind  the 
implementation  can  be  applied  to  Ada  with  little  if 
any  modifications. 
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An  •fTiciant  impUmantation  for  true  maaaage- 

paaaing  machines  is  currently  being  investigated. 
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Discussion 


Queslioa  G.  HAMEETMAN 

SbouM  you  not  put  more  emphawis  oo  the  fact  that  you  problem  only  exists  in  a  beierogeneous  processor  environment? 
Almost  all  modOT  processors  have  solved  your  problem  for  homogeneous  system,  eg  Transputer  with  message  passing 
model,  R4400  with  a  separate  cache  snooping  bus. 

Reply 

You  are  right  in  stating  that  most,  if  not  all,  microprocessors  with  cache  provide  some  cache  consistency  protocol 
capabilities.  However,  the  problem  is  in  the  way  these  components  are  in  real  embedded  systems,  airborne  or 
ground.  The  fact  is  that  most  embedded  systems  are  build  around  the  Motorola  68000  family,  Imel  8086  family  and, 
to  a  lesser  extent,  the  AMD  29000  and  Intel  i860.  These  processors  are  put  in  cards  with  some  local  memory  and  I/O 
devices  and  access  other  cards  over  a  backplane  bus.  The  most  common  bus  is  the  VM£  bus,  but  the  NuBus,  the 
Multibus  11  and  some  other  busses  are  also  used.  Typically,  snoopy  cache  consistency  protocols  cannot  be  used  across 
these  busses  because  of  the  design  of  the  bus  interfaces. 

The  thinwire  ^rproach  allows  one  to  implement  real-time  muid-lasking  systems  on  multi-processors  built  from  such 
cards.  U  also  allows  one  to  port  with  no  modificaiioa  software  components  (written  in  a  high  level  language)  and  entire 
subsystems  (components  and  design)  to  machines  with  no  shared  memory,  such  as  a  Transputer-based  muliprocessor. 
The  components  I  have  in  mind  are  tasks,  such  as  server  tasks  and  high  level  (task-based)  device  drivers,  which  could  be 
written  in  Ada.  The  thinwire  approach  thus  provide  for  code  and  even  design  re-use. 

(Question  L.  HOEBEL 

Depending  somewhat  on  multi-processor  configuration,  don't  you  somewhat  overstau:  the  case  against  snoopy  cache 
coherency  protocols  and  is  the  predictability  of  cache  perfonnance  not  just  like  translation  (look  aside)  bufl'ers  for  page 
tables?  ie,  can't  you  determine  average  perfonnance? 

Reply 

When  building  real-time  systems  in  a  high  level  language  such  as  C  or  Ada,  one  does  not  have  control  over  the  allocation 
of  data  to  memory  for  static  data  and  data  allocated  in  stack  frames;  If  any  of  these  data  is  shared  as  happens  when  a 
variable  local  to  an  Ada  task  is  passed  as  a  parameter  in  all  entry  call,  false  dialing  can  occur.  The  implication  of  this, 
and  the  implication  that  snooping  is  controlled  at  the  page  level,  is  that  snoop  cycles  can  occur  wherever  a  local  variable 
is  modified.  This  is  the  case  with  the  MC  68040,  which  must  be  used  in  a  write-through  mode  for  snooping  to  work. 
Therefore,  I  do  not  think  that  I  am  overstating  the  case  over  using  snoopy  protocols,  at  least  not  for  the  type  of  multi¬ 
processor  I  considered,  which  is  representative  of  a  large  number  of  re^-time  platforms. 

Of  course,  the  real  cost  of  snooping  in  a  given  application  depends  on  the  underlying  machine  and  on  the  application 
itself.  Studies  of  the  cost  of  snooping  do  exist.  These  studies  looked  at  "typical"  applications.  Such  "typical"  applications 
could  behave  quite  differently  from  a  specific  real-time  plication. 

The  in  ,:iredictability  introduced  by  cache  consistency  protocols  is  not  the  same  as  the  impredictability  introduced  by 
translation  lookaside  buffers  or  by  caches  that  are  not  kept  consistent  in  hardware.Tbe  difference  is  that  with  cache 
consistency  protocols,  the  state  of  a  given  cache  in  no  longer  a  function  of  the  addressing  history  of  its  prtKessor,  but 
also  a  function  of  the  addressing  history  of  all  processors.  Without  cache  consistency  protocols,  it  is  possible  to 
determine  what  addresses  will  be  generated  by  a  processor,  wd  tberefcae  to  know  what  the  state  of  its  cache  (and  TLB) 
will  be,  if  the  input  data  to  the  program  is  known  (to  determine  the  execution  path)  and  if  asynchronous  intemipts  do  not 
occur. 

Quesuon  C.  BENJAMIN 

Which  message  passing  machine  are  you  considering  for  your  implementation? 

Reply 

A  specific  machine  has  not  been  selected.  Rather,  the  investigation  has  so  far  concentrated  on  finding  an  efficient 
machine-independent  protocol  for  interprocessor  communication.  Only  then  will  actual  machines  be  selecied  and  the 
perfonnance  of  the  implememation  measured. 
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1  introduction 

Modem  aircralt.  military  or  civil,  are  incorporating 
all  the  most  up-to-date  technology  in  all  fields  of 
human  sciences.  There  is  an  increasing  tendency 
to  develop  digital  control  systems  which  are 
rapidly  replacing  analog  control  systems  in  all 
areas,  especially  in  the  traditional  ones  such  as 
engine  control,  power  generation,  fuel  and 
enviromnental  control  etc. 

Digital  systems  are  already  acknowledged  as 
unreplaceable  in  avionics  and  are  fast  growing  also 
in  flight  control  systems.  Indeed  they  are 
responsible  for  the  increa.scd  sophistication  of 
modem  aircraft  and  for  the  birth  and  success  of 
avionics  as  we  now  know  it. 

The  net  result  is  that  whore  in  the  first  generation 
of  jet  planes  there  were  no  on  board  computers, 
modem  aircraft  may  have  more  than  twenty,  with 
single  or  multiple  32  bit  microproces.sors.  multiple 
megabytes  of  RAM  and  sophisticated  real  time 
operating  systems. 

Figure  I  may  be  a  good  example  of  the  tendency 
portrayed  before,  with  the  trend  clearly  highlighted 
for  future  aircraft. 


Fig.  1  -  Number  of  on  board  computers 


Aircraft  interiors  have  dramatically  changed  in  the 
last  twenty  years:  a  modem  combat  aircraft  is 
mostly  an  empty  shell  with  lots  of  space  for 
equipment  mounting  and  there  is  very  little 
resemblance  to  older  mechanical  aircraft.  Every 
computer  for  which  we  find  a  place  is  something 
which  can  augment  the  aircraft  capabilities.  This 
is  much  more  felt  in  combat  aircraft  (where  space 
is  at  a  premium  and  every  cubic  inch  counts)  than 
in  civil  aircraft. 


As  a  result  also  aircralt  design  has  changed,  calling 
in  professions  which  were  not  present  in  the  past. 
Where  aeronautic  engineers  were  predominant  in 
the  pa.st.  they  are  now  just  a  part  of  the  whole 
design  cycle;  the  presence  of  electronic  engineers 
and  software  engineers  is  now  growing  and  as 
systems  get  more  complex  shall  become  the 
predominant  category  of  professionals  engaged  in 
the  design.  They  are  the  people  who  design  the 
mission  capabilities  of  the  aircraft,  and  in  the  case 
of  unstable  airplanes  they  are  also  the  people  who 
keep  the  aircraft  flying.  Software,  as  already 
written  in  many  presentations,  is  fa.st  becoming  the 
most  expensive  activity  and  the  longest  in  temis 
of  application  tuning. 

System  design  and  testing  can  be  briefly  described 
with  the  full  model  depicted  in  figure  2  which  is 
also  already  known  in  different  fomis  and  which 
is  also  widely  criticised  as  being  oversimplified.  In 
this  instance  the  author  only  wishes  to  use  it  to 
higltiighl  the  area  of  the  system  development 
which  is  the  target  of  this  presentation,  namely  the 
hardware  to  software  integration. 
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Fig.  2  -  Aircraft  prototypes  design  phases 


2  Task  definition 

Hardware  to  software  integration  definition  is 
defined  as  that  activity  whose  aim  is  the  marrying 
up  of  the  .software  previously  host  tested  with  the 
equipment  frc.shly  manufactured  by  a  supplier. 
Output  of  this  activity  is  therefore  a  combination 
of  a  reasonably  bug  free  computer  and  of  a 
software  load  reasonably  tested  and  certified 

The  activity  can  be  split  in  three  main  areas  : 
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-  familiarisation  with  the  equipment: 

-  static  testing; 

•  dynantic  testing. 

3  Areas  of  work 

3.1  Familiarisation 

This  is  that  part  of  the  activity  which  is  more  akin 
to  art  than  to  science:  past  experience  suggests  that 
a  hardware  man  with  knowledge  of  practical 
hardware  (usually  the  equipment  engineer)  and  of 
instruments  for  debugging  (i.e.  emulators  and  usu:d 
laboratory  stuff)  and  one  or  more  software  people 
make  up  the  test  team  to  tackle  the  unknown 
quantity.  The  first  tests  in  downloading  and 
running  part  of  the  software  usually  fail  miserably, 
so  it  is  time  for  the  hardware  man  to  delve  in  the 
deepest  recesses  of  the  computer  using  the 
emulator  and  maybe  the  logic  state  analyzer  in 
order  to  discover  why  that  interrupt  is  not  high, 
what  is  contained  in  those  two  bytes  on  top  of  the 
memory,  what  is  actually  written  in  the  chip 
registers  etc. 

3.2  Static  testing 

As  soon  as  the  team  succeeds  in  running  a  few 
example  programs  on  the  target  hardware,  it  is  time 
to  start  downloading  also  part  of  the  software 
which  is  to  be  officially  tested  and  it  is  time  also 
to  start  testing  program  stubs  which  stimulate  the 
hardware  input/output,  in  order  to  understand 
tetter  how  the  driver  software  works  (if  it  works 
at  all),  how  long  it  takes  to  set  a  discrete  output 
or  to  read  a  dijgital  input,  and  how  this  affects  the 
global  scheduling. 

Last  but  not  least,  measuring  the  time  it  takes  to 
the  program  to  run  is  also  apt  to  deliver  nasty 
sunrises,  with  the  possibility  that  the  program,  as 
it  is,  might  not  fit  inside  the  scheduled  time. 

This  area  of  testing  also  involves  the  setting  of 
simple  sequences  to  be  executed  as  input  to  the 
target  computer  and  the  recording  of  the  outputs. 
Many  tests  can  indeed  be  performed  with  these 
simple  guide-lines. 

3.3  Dynamic  testing 

This  area  covers  all  the  testing  which  is  perfonned 
by  implementing  a  clo.sed  loop  test  environment, 
between  the  target  computer  and  a  test  harness 
capable  of  stimulating,  morutoring  and  recording 
all  the  data  transactions.  This  is  the  area  which  has 
lately  become  the  one  ntost  in  need  of  growth  in 
terms  of  test  harnesses  and  is  the  one  which  shall 
the  subject  of  this  paper,  illustrating  how  one  of 
these  systems  has  come  to  be,  how  it  has  grown 
to  be  an  invaluable  tool  in  perfonning  the  hardware 
to  software  integration  and  system  integration  and 
testing. 


4  AIDASS 

AIDASS  stands  for  Advanced  Integrated  Data 
Acquisition  and  Stimulation  /  Simulation  System, 
it  is  an  acronym  which  sprang  up  during  the  first 
years  of  the  EFA  project  (in  the  Tornado  years 
everybody  had  a  DASS.  with  EFA  it  has  become 
advanced  and  integrated)  and  has  teen  applied 
with  some  slight  modification  to  the  data 
acquisition  system  of  the  four  EFA  partner 
companies. 

5  Some  history 

Our  job  started  in  1987  as  a  project  for  a  Tornado 
data  acquisition  system,  whose  specifications  were 
very  simple; 

-  the  system  had  to  acquire  a  number  of  data, 
namely  analogue  and  digital: 

-it  had  to  act  as  ISS3  bus  controller  or  bus 
monitor  and  at  the  same  time  simulate  the 
missing  remote  terminals  on  two  buses: 

-  it  had  to  simulate  a  number  of  missing 
equipment  which  talked  over  a  Panavia  Starxlard 
Seri^  Line. 

-  it  had  to  record  the  activities  performed  in  order 
to  be  able  to  get  a  report  of  the  test  or  to  be 
able  to  analyse  any  malfunction. 

-  of  course  it  had  to  be  user  friendly,  easy  to  use, 
modular  for  an  easy  future  expansion. 

A  first  analy.sis  of  these  requirements  was  coupled 
with  a  very  simple  analysis  of  aircraft 
architectures,  in  the  electronic  department:  these 
can  be  divided  roughly  in  three  areas,  general 
systems,  avionics,  flight  control  systems.  These 
systems  have  fairly  different  layout  and  needs  : 

1)  general  systems  have  a  predominance  of  digital, 

-  analog,  frequency  etc,  signals  over  copper, 
looms  of  wires  and  one  or  more  buses  (which 
can  be  1553  or  else)  over  which  a  small  traffic 
runs; 

2)  avionics  see  a  predominance  of  buses  with 

-  heavy  traffic,  and  little  if  nothing  at  all  in  the 
analog  and  digital  signal  field; 

3)  flight  control  systems  have  a  mixed 

-  enviroiunent.  more  similar  to  general  systems, 
but  with  very  stringent  timing  requirements  and 
a  strong  need  for  closed  loop  simulations. 

We  had  to  design  something  which  was  general 
enough  to  be  able  to  cope  these  systems.  This 
means  a  high  modularity,  with  the  possibility  of 
inserting  pieces  as  needed,  pieces  which  can  be 
high  speed  simulators,  analog  control  boards,  bus 
interface  cards  etc.  There  is  a  need  for  a  number 
of  I/O  monitoring,  but  it  can  be  safely  restricted 
to  a  few  hundred  points,  not  thousands.  The  rate 
of  the  system  has  to  be  as  close  to  the  aircraft’s 
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1  Introduction 

Modem  aircralt.  military  or  civil,  are  incorporating 
all  the  most  up-to-date  technology  in  all  fields  of 
human  sciences.  There  is  an  increasing  tendency 
to  develop  digital  control  systems  which  are 
rapidly  replacing  analog  control  systems  in  all 
areas,  especially  in  the  traditional  ones  such  as 
engine  control,  power  generation,  fuel  and 
environmental  control  etc. 

Digital  systems  are  already  acknowledged  as 
unreplaceable  in  avionics  and  are  fast  growing  also 
in  flight  control  systems.  Indeed  they  are 
responsible  for  the  increased  sophistication  of 
modem  aircraft  and  for  the  birth  and  success  of 
avionics  as  we  now  know  it. 

The  net  result  is  that  where  in  the  first  generation 
of  jet  planes  there  were  no  on  board  computers, 
modem  aircraft  may  have  more  than  twenty,  with 
single  or  multiple  32  bit  microproces.sors,  multiple 
megabytes  of  RAM  ;uid  sophisticated  real  time 
operating  systems. 

Figure  1  may  be  a  g<K)d  example  of  the  tendency 
portrayed  before,  with  the  trend  clearly  highlighted 
for  future  aircraft. 


Fig.  1  -  Number  of  on  board  computers 


Aircraft  interiors  have  dramatically  changed  in  the 
last  twenty  years;  a  modem  combat  aircraft  is 
mostly  an  empty  shell  with  lots  of  space  for 
equipment  mounting  and  there  is  very  little 
resemblance  to  older  mechanical  aircraft.  Every 
computer  for  which  we  find  a  place  is  something 
which  can  augment  the  aircraft  capabilities.  This 
is  much  more  felt  in  combat  aircraft  (where  space 
is  at  a  premium  and  every  cubic  inch  counts)  than 
in  civil  aircraft. 


As  a  result  also  aircraft  design  has  changed,  calling 
in  professions  which  were  not  present  in  the  past. 
Where  aeronautic  engineers  were  predominant  in 
the  past,  they  are  now  just  a  part  of  the  whole 
design  cycle;  the  presence  of  electronic  engineers 
and  software  engineers  is  now  growing  and  as 
systems  get  more  complex  shall  become  the 
predominant  category  of  pn)fessionals  engaged  in 
t.he  design.  They  are  the  people  who  design  the 
mission  capabilities  of  the  aircraft,  and  in  the  case 
of  unstable  airplanes  they  arc  also  the  people  who 
keep  the  aircraft  flying.  Software,  as  already 
written  in  many  presentations,  is  fast  becoming  the 
most  expeasivc  activity  and  the  longest  in  temis 
of  application  tuning. 

System  design  and  testing  can  be  briefly  described 
with  the  fall  model  depicted  in  figure  2  which  is 
also  already  known  in  different  fonns  and  which 
is  also  widely  criticised  as  being  oversimplified.  In 
this  iastance  the  author  only  wishes  to  use  it  to 
higlilight  the  area  of  the  system  development 
which  is  the  target  of  this  presentation,  namely  the 
hardware  to  software  integration. 
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Fig.  2  -  Aircraft  prototypes  design  phases 


2  Task  definition 

Hardware  to  software  integration  definition  is 
defined  as  that  activity  whose  aim  is  the  marrying 
up  of  the  software  previously  host  tested  with  the 
equipment  freshly  manufactured  by  a  supplier. 
Output  of  this  activity  is  therefore  a  combination 
of  a  reasonably  bug  free  computer  and  of  a 
software  load  reasonably  tested  and  certified 

The  activity  can  be  split  in  three  main  areas  ; 


•  • 


Presented  at  an  AGARD  Meeting  on  Aerospace  Software  Enpneering  for  Advanced  Systems  Architectures’,  May  1993. 


•  • 


«) 


one  as  possible,  which  for  our  aiarafts  usually 
means  around  50  Hz.  with  the  possibility  of 
including  high  rate  pans. 

In  order  to  fultll  these  requirements  a  market 
survey  was  conducted  to  Icam  of  the  current  state 
of  the  an  of  the  data  acquisition  systems  and 
whether  they  could  be  the  equal  to  the  task. 
Unfortunately  all  the  common'  data  acquisition 
systems  we  surveyed  fell  short  in  some  fields; 
usually  they  were  very  capable  in  their  chosen  field 
with  capabilities  of  million  of  points  acquired  in 
one  second.  PCM.  data  reduction  and  some  were 
even  capable  of  housing  simple  simulation  to 
stimulate  the  target  computer.  Usually  they  could 
not  do  all  together,  and  as  a  certainty  they  could 
not  act  as  closed  loop  machines,  not  unless  their 
architecture  changed  drastically. 

So  we  were  in  the  position  that  we  had  to  devise 
something  of  our  own  to  fill  in  our  need. 

6  Start  of  AIDASS 

6.1  Birth  of  an  architecture 

The  first  problems  we  faced  regarded  the  type  of 
the  architecture  to  be  used:  did  we  have  to  go  for 
a  centralised  sy.stem  or  for  a  distributed  system 
What  kind  of  I/O  cards  would  we  be  using  What 
machines  would  we  be  using  ?  What  operating 
system  '1  and  so  on  ... 

An  additional  market  survey  was  conducted  to 
learn  about  computers  aird  I/O  systems,  and  as  a 
result  an  embryo  architecture  started  to  appear. 
VME  in  those  days  was  starting  to  rise  powerfully 
as  I/O  subsystem,  so  we  almost  took  it  for  granted. 
From  the  software  point  of  view  then,  our 
historical  environment  has  always  been  a 
DIGITAL  VMS  one.  with  no  tics  except  for 
sporadic  contacts  with  the  UNIX  world.  As  VMS 
5.0  and  DECwindows  had  just  been  announced,  it 
also  seemed  natural  to  turn  to  them  in  order  to 
capitalise  on  the  internal  .software  expertise  on 
VMS  and  to  build  a  graphical  user  interlace  based 
on  DECwindows  in  order  to  build  on  a  known 
international  standard  as  X-Window.  We  had  some 
of  the  pieces  and  we  had  to  tie  them  together  ;  a 
user  interface.  I/O  cards  and  CPUs  to  control  them. 
One  of  the  choices  had  been  made  already,  we 
were  going  for  a  distributed  processing  system. 
ADA  would  be  used  as  far  as  possible  for  the  same 
rea-sons  as  VMS  and  also  for  practical  reasons,  (it 
was  going  to  be  the  language  used  for  the  writing 
of  the  simulations  by  our  partner  companies,  so  if 
we  wanted  to  be  able  to  share  something  with 
them,  we  had  to  design  something  able  to 
accommodate  ADA  programs).  VAXeln  was  also 
chosen  as  the  only  way  to  run  VMS  ADA 
programs  in  the  easiest  possible  way.  What  we 
were  still  missing  was  a  way  of  shuffling  the  data 
to  and  from  the  parts  comprising  the  system  and 
to  connect  them.  One  of  the  methods  we  looked 
for  was  a  many  ported  ram  acting  as  glue.  We 


didn't  actually  found  one  in  the  first  round,  but  we 
went  close  enough,  choosing  a  bus  adapter  from 
QBUS  to  VME  with  dual  ported  nun  between  the 
buses.  The  first  AIDASS  was  bom.  Its  architecture 
was  as  illustrated  in  pic.  3).  with  a  VAXstation 
3500  acting  as  user  interface  and  real  time 
recording,  a  RTVax  3200  which  was  to  host  ail 
the  simulations  and  a  VME  subsystem  for  the  I/O. 
It  was  easy  to  find  a  VME  bus  extender  for  those 
occasions  where  one  crate  was  not  enough  to  host 
the  I/O  cards. 


Fig.  3  -  First  AIDASS  architecture 


6.2  Software 

Well,  the  birth  of  the  architecture  was  painless 
enough,  now  what  about  the  software  ? 
DECwindows  was  something  so  new  that  nobody 
knew  much  about  it.  much  less  how  to  use  it  in 
conjunction  with  ADA.  In  those  days  (remember 
that  we  are  talking  about  1988)  a  proper 
programmer  used  C  with  X-Window  (90  %  still 
do  it  today),  but  luckily  we  had  some  examples 
provided  with  DECwindows  which  helped  us  start. 
That  was  one  task,  together  with  all  the  underlying 
software  to  handle  the  many  tasks  of  the  user 
interface. 

Another  one  was  to  think  of  the  interfaces  with  the 
external  equipment,  with  the  VME  in  the  first 
place,  how  to  program  it  and  how  to  interface  with 
it.  Having  chosen  VMS  we  also  looked  at  a 
compiler  for  the  VME  boards.  The  best  processor 
we  were  able  to  find  were  Motorola  68020  but 
ADA  for  them  was  not  the  best  option.  We  then 
chose  C  as  language  for  the  VME  epus,  with  the 
pSOS*"’  operating  system  kernel  to  act  as 
scheduler. 

VAXeln  with  ADA  for  the  RTVax  was  another 
task,  with  no  conceptual  ground  to  break  and  not 
technically  difficult. 

The  basis  of  the  system  anyway  is  not  in  the 
software  but  in  the  underlying  database,  which 
contains  all  the  infonnation  used  to  run  the  tests. 
The  databa.se  is  really  what  gives  to  the  AIDASS 
its  capabilities,  because  it  contains  an  adequate 
description  of  everything  on  the  rig  or  bench,  a 
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complete  interface  description  of  all  the  interesting 
input/output  of  the  equipment  present  on  the  rig 
with  names,  engineering  units,  scaling 
infonnations,  and  in  the  case  of  bus  signals  also 
transaction  tables,  subgroups  and  bit/byte/word 
position  and  LSB  and  MSB.  The  database  is  as 
complex  as  it  looks,  but  for  us  it  would  be  a 
by-product  of  the  engineering  activity,  because 
such  an  ICD  database  has  to  be  compiled  by  the 
engineers  for  the  EFA  activities.  It  uses  the 
INGRES  DBMS  and  we  get  the  data  from  it, 
adding  just  those  infomiation  needed  to  link  the 
logic^  signals  of  the  computers  with  the  interfaces 
present  on  the  rig  (this  means  telling  AIDASS 
which  computer  signals  went  to  which  interface 
card). 

6.3  Experience 

To  design  the  system  software  we  adopted  the 
standard  tools  used  for  aircraft  software  design, 
CORE  for  requirement  and  HOOD  for  software 
basic  and  detailed  design.  In  particular  this  latter 
technology  was  particularly  suited  to  the  event 
driven  X-Window  environment,  while  we  had 
some  problem  to  describe  the  same  environment 
using  the  procedural  CORE.  It  was  done 
nonetheless.  After  6  months  of  coding  finally  the 
first  product  was  ready  to  be  used.  During  the 
coding  phase  many  were  the  problems  tackled  and 
solved  by  the  engineers;  among  them  the  toughiest 
had  to  do  with  DECwindows.  Implementing  a  user 
interface  using  X-Window  proved  to  be  a  lengthy 
process,  with  many  revisions  to  each  mask  to  get 
the  right  position  of  the  text,  the  right  font, 
attention  was  put  on  not  superimpose  words  and 
so  on.  All  in  all  a  skilled  developer  could  not 
achieve  more  than  2  or  three  masks  per  day  when 
they  were  simple,  just  because  of  the  tediousness 
of  the  process.  Today  there  are  tools  which 
enormously  simplify  this  design  phase  and  a 
skilled  developer  can  chum  out  ten  complex  masks 
per  day  easily,  testing  them  in  real  time  with 
facilities  given  by  the  tool,  whereas  we  were 
compelled  to  write  program  stubs  to  test  the  mask. 

On  the  VME  side  there  were  the  usual  skimiishes 
during  the  familiarisation  with  VME  CPUs,  the 
problems  in  understanding  how  interrupts  were 
generated  and  how  we  could  trap  them  with  our 
operating  system  kernel  to  provide  the  scheduling 
required. 

A  continuous  feedback  with  the  users  was  needed 
to  solve  some  points  when  the  software  designers 
didn'  t  know  how  to  best  pmceed  and  many 
changes  were  made  to  emphasize  user  friendliness 
and  the  general  usability  of  the  system.  A  set  of 
tools  were  developed  to  take  care  of  the  database 
which  more  and  more  came  to  represent  the  central 
part  of  the  system.  Database  creation  and 
population  tools  and  the  very  important  tool  of 
database  consistency  checking  came  slowly  into 
existence.  Consistency  you  had  to  have  in  order  to 


avoid  two  or  more  signals  sharing  the  same  output 
pin,  or  the  incorrect  scaling  of  some  data  (a 
boolean  entity  must  not  have  more  than  two 
meanings,  analog  signals  must  have  limitations 
etc.). 

6.4  The  progress 

The  progress  was  slow,  much  more  so  since  the 
compiling  and  testing  of  the  ADA  program  took 
more  and  more  time,  with  unforeseen  side  effects 
of  using  DECwindows  slowly  creeping  in.  Also  the 
documentation  was  not  totally  satisfactory, 
sometime  ambiguous,  and  a  number  of  bugs  in  the 
X-Window  server  were  uncovered,  some  were 
circumvented  and  patches  were  delivered  by 
Digital.  The  application  was  getting  very  big, 
totalling  almost  200000  lines  of  code,  between 
ADA.  C,  and  UlL.  The  real  time  recording  took 
some  fiddling  with  VMS.  but  eventually  it  all 
started  to  work. 

6.5  The  result 

What  we  got  in  the  was  a  system  which  was  able 
to  perfonn  tests  automatically,  defining  for  each 
test  the  variables  which  had  to  be  recorded,  those 
which  had  to  be  stimulated  and  how  (with  a  limited 
library  of  simple  stimuli  such  as  sawtooth,  ramp 
etc),  and  what  had  to  be  recorded.  All  of  these 
activities  were  perfonned  by  clicking  with  the 
mouse  on  appropriate  ntenu  and  lists.  Then  the  lest 
was  started  and  the  data  were  shown  in  the  chosen 
engineering  units  fonnat,  with  either  an  optional 
graphical  repre.scntation  or  signal  true  input/output 
fonnat  could  be  displayed  in  parallel.  At  the  end 
of  the  test,  the  data  collected  could  be  analysed 
using  some  embedded  facilities  which  allowed  to 
plot  the  variables  in  time  plots  and  allowed  some 
matching  with  other  variables.  During  the  test  the 
input  variables  could  be  stimulated  at  run  time  by 
clicking  on  the  variable  and  defining  the  type  of 
stimulus,  its  length  and  amplitude. 

Now  the  time  had  come  to  use  the  AIDASS  for  a 
real  situation,  connecting  it  to  a  real  on  board 
computer.  Time  to  populate  a  real  database  with 
real  aircraft  data,  check  it  and  then  see  what  came 
out  of  the  I/O  boards. 

6.6  Under  operation 

After  a  few  days  of  working  with  the  database 
tools,  one  thing  was  clear:  we  had  to  have  a  better 
tool,  the  one  we  had  now  was  too  complex  and 
time  consuming.  The  insertion  of  the  data  was 
riddled  with  difficulties  and  too  often  mistaken 
data  was  inserted  with  no  help  from  the  system, 
except  at  check  time  when  an  avalanche  of  errors 
were  detected  by  the  system.  In  addition  many 
sntall  difficulties  were  experienced  with  the  user 
interface,  which  is  only  understandable  as  the 
product  was  brand  new  out  of  the  developers’ 
hands.  With  real  data  we  also  found  that  system 
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initialization  time  was  tar  too  high  when  an  high 
number  of  data  was  inserted  (it  might  be  as  high 
as  half  an  hour).  Also  the  checking  process  was 
found  faulty  and  errors  were  found  during  the  test 
run  due  to  inaccurate  checking  of  the  database. 

All  of  these  teething  pn^blems  were  investigated 
and  solutions  were  proposed  to  the  users.  It  took 
more  than  one  round  to  get  most  of  the  problems 
ironed  out. 

The  simulation  part  was  easily  the  most  powerful 
part  of  the  system,  because  by  using  the  variable 
names  defined  in  the  system  database,  a  program 
was  able  to  access  every  resource  in  the  system 
and  change  it  at  will.  A  few  difficulties  were  met 
at  first  with  the  definiti<'n  of  the  interface  between 
the  simulation  and  the  system  and  that  was  ironed 
out  by  the  development  of  a  tool  which 
automatically  extracted  the  interface  from  the 
database  and  built  it. 

6.7  The  second  generation 

While  we  were  happily  developing  our  software, 
the  external  world  started  to  change  dramatically. 
Digital  did  not  manufacture  the  QBUS 
workstations  any  more,  and  we  were  stranded  with 
an  architecture  which  was  heavily  based  on  QBUS. 
We  had  to  start  developing  something  like  ten 
more  of  these  AIDASS  nodes  and  clearly  we  could 
not  afford  to  find  again  ourselves  in  this  situation. 
All  of  this  prompted  us  to  think  of  ways  to  avoid 
the  occurrence  of  these  problems  again.  We 
performed  a  second  market  survey  looking  for 
hardware  and  what  we  found  was  disconcerting: 
workstation  manufacturers  were  steering  clear  of 
I/O  buses  as  much  as  possible,  the  market  was 
moving  toward  busless  workstations  which  were 
low-cost  but  which  were  clearly  not  well  suited  to 
our  task. 

We  had  to  take  an  evolutionary  step,  while  trying 
to  save  as  much  as  possible  of  the  software  written. 
Based  on  the  experience  done  with  the  first  node, 
the  first  thing  was  to  decouple  all  real  time 
activities  from  the  non  strictly  real  time.  Second 
prerequisite  was  the  modularity  of  the  system, 
which  was  to  be  retained  at  all  costs.  These 
requirements  led  us  to  rethink  also  about  the  other 
components  of  the  architecture  and  to  clearly  label 
them  as  separate  components  if  possible,  in  order 
to  allocate  for  them  a  separate  piece  of  hardware. 


According  to  our  requirentents  we  built  a  logical 
architecture  depicted  in  fig.  4.,  separating  the  real 
time  part  from  the  non  real  time.  Then  we  tried  to 
find  corresponding  pieces  of  hardware  to  transform 
the  logical  into  physical.  Some  of  the  pieces  we 
already  had,  such  as  the  VME.  the  simulation  part, 
and  the  user  interface  could  be  reused  almost 
totally.  WTiat  we  lacked  mo.stly  was  the  common 
data  area  and  the  link  between  it  and  the  user 
interface.  Many  alternatives  were  examined,  and  in 
the  end  discarded  because  it  meant  tying  ourselves 
to  a  .specific  bus  on  the  user  interface  pan,  .so  we 
reached  the  decision  of  totally  uncoupling  it  from 
the  rest  of  system,  by  connecting  the  VAXstation 
to  the  real  time  using  Ethernet.  On  the  VME  side 
there  had  been  also  a  development  with  the  advent 
of  the  RTVax  chip  on  VME  boards,  and  it  was 
easy  to  put  one  of  these  new  RTVaxes  to  handle 
the  communication  between  the  two  pieces. 

We  had  a  new  architecture,  and  what  was  best  we 
had  saved  almost  90%  of  the  software  already 
written,  we  only  had  had  to  rewrite  part  of  the 
interface  software. 

W^at  came  out  looked  even  more  impressive  than 
the  first  architecture,  actually  costed  much  le.ss  and 
was  highly  flexible. 


Fig.  5  -  The  new  architecture 
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6.8  New  experiences 

This  new  architeccure  was  soon  put  to  the  test  on 
a  couple  of  benches,  while  the  first  one  was 
finishing  its  tests  on  another  bench.  The  new  one 
proved  soon  to  be  much  better  than  the  older  one. 
thanks  also  to  the  fact  that  more  powerfiil  hardware 
had  been  employed  as  workstations  and  VME 
cpus.  but  still  bugs  crept  in.  especially  in  the  1S53 
handling.  We  had  a  very  tough  1553  bus  to  handle 
and  it  was  very  hard  to  describe  the  transaction  in 
a  complete  maimer,  both  because  it  was  very  long 
and  complex  and  also  because  it  had  a  complex 
structure  with  multirate  signals  on  the  same 
subaddress  and  a  very  high  data  bus  load. 

The  database  went  under  a  couple  of  major 
changes  with  the  addition  of  a  few  data  fields  in 
order  to  accommodate  the  mo.st  generic  bus  of  all 
and  with  it  went  also  modifications  of  the  database 
check  tool  which  by  now  had  been  speeded  up  of 
an  order  of  inagnimde.  After  the  first  grumbling, 
the  test  people  were  now  quite  happy  of  this  new 
tool  as  they  appreciated  the  breadth  of  possibilities 
now  available.  Thanks  to  X-Window,  the  setting 
up  of  test  databases  was  very  easy,  boring,  because 
you  had  to  choose  from  a  very  long  list  the  name 
of  the  variables  you  wanted  to  handle  and  how. 
The  miming  of  the  system  was  quite  easier  now 
after  many  bouts  with  the  users  and  as  a 
consequence  real  work  could  be  now  started  and 
the  tool  depended  upon  for  its  results. 

Yes,  this  was  the  turning  point  of  all  our  activity, 
the  fact  that  the  tool  could  be  safely  tmsted  to  give 
the  right  results,  so  that  it  could  be  used  to 
diagnose  the  system  health,  and  thanks  to  the 
possibility  of  dynamically  simulating  the  missing 
equipment  in  all  of  their  functionalities,  to 
anticipate  on  the  HW/SW  benches  sirne  of  the  tests 
related  to  the  system. 

6.9  Other  developments 

Once  the  software  stabilised,  other  capabilities 
have  been  added,  expanding  upon  the  visualization 
of  the  data  in  engineering  units,  in  order  to  give 
the  user  the  maximum  flexibility;  an  advanced 
error  injection  was  developed  to  allow  further 
debugging  of  the  systems  under  test,  both  from  the 
discrete/analogue  side  and  the  bus  side.  An 
optimization  was  perfonned  on  the  software  so  as 
to  wring  every  ounce  of  power  from  the  cpus  and 
as  a  consequence  now  the  system  is  capable  of 


supponing  very  high  loads  of  I/O  intensive  rigs. 
Faster  than  the  base  rate  simulations  and  data 
acquisitions  are  easily  handled  and  iitserted 
painlessly  in  the  system,  with  rates  going  now  up 
to  2  Khz  per  channel.  Multiple  cpus,  even  RISC 
cpus.  mnning  each  a  simulation  program  can  mn 
concurrently  as  long  as  the  writer  is  careful  about 
the  data  they  exchange  and  manipulate. 

The  limitations  are  still  there,  though,  and  we  still 
do  JM  3  powerful  data  acquisition  only 

system,  it  still  is  le.ss  and  more  than  that,  a  mixture 
which  best  caters  to  our  needs. 

A  spin-off  of  this  adventure  has  been  tlie  recent 
porting  of  the  simulation  software  module  base 
under  VMS.  to  allow  for  the  testing  of  simulation 
software  under  VMS.  The  software  will  run  not  in 
the  real  time,  but  will  be  clocked  as  under  real 
time,  allowing  a  thorough  debugging  of  the 
modules  and  interfaces. 

This  idea  is  now  being  expanded  upon  and  we  are 
invcstingating  ways  of  exapirding  this 
methodology  also  for  software  /  software 
integration  on  the  host,  for  the  final  pan  of  it  at 
least  to  allow  for  an  easy  transition  between  this 
phase  and  the  hardware  /  software  integration 
phase,  with  a  consistent  tool  and  interface.  This  is 
being  studied  into  right  now. 

7  Conclusions 

This  is  a  short  history  of  how  a  complex  data 
acquisition  system  has  come  into  existence,  to 
satisfy  the  needs  of  modem  aircraft  testing  during 
the  hardware  software  integration  and  integration 
te.siing. 

What  we  now  have  in  our  hands  is  a  complex  and 
composite  tool,  capable  of  supporting  testing  from 
the  last  stages  of  software  /  software  integration 
till  the  end  of  all  the  integration  testing  on  a  system 
rig- 

It  is  still  changing  and  adding  in  purposes  and  in 
supported  hardware  to  cater  for  all  needs  envisaged 
in  our  work. 

We  believe  that  it  shall  be  more  than  good  enough 
to  reduce  the  workload  on  the  test  engineers  and 
to  allow  them  to  better  analyse  the  equipment 
under  test  as  required  by  the  complexities  of 
modem  computers  and  tiieir  embedded  functions. 


Discussion 

Questioo  D.  NAIRN 

If  you  were  starting  all  over  again,  knowing  what  you  know  now.  what  would  you  do  different? 

Reply 

I  would  probably  go  for  mme  open  systems  with  Unix  workstations  and  Unix  supported  targets  on  VME  (Lynx -OS,  VX- 
Works,  etc).  I  would  not  change  the  architecture  because  I  think  that  for  the  time  teing,  it  is  the  most  functional  for  the 
tasks  it  has  to  face,  namely  to  handle  inputs  god  outputs  to/from  the  target  The  system  has  to  acquire  data,  think  upon  it 
and  react  a  closed  loop  situation.  In  acWtion,  I  would  like  to  scrap  Ada,  because  it  is  highly  not  portable  among  systems. 
I  would  better  use  ANSI  C. 


SOFTWARE  TESTING  PRACTICES 
AND  THEIR  EVOLUTION  FOR  THE 


Patrizia  Di  Cario 
Alenia-Finmeccanica  S.p.A. 
Corso  Marche  4 1 
10146  Torino 
Italy 


SUMMARY 

Experience  within  an  aerospace  company  on  solving 
specific  problems  in  the  host  testing  of  embedded 
software  is  described. 

Operational  applicability  and  exploiution  of  tools 
off-the-shelf,  solutions  for  the  management  of  both 
process  and  testing  infonnation.  and,  finally,  the 
impact  of  the  possible  use  of  formal  methods  for  the 
automatic  generation  of  test  cases  are  investigated 
and  assessed  from  the  user  point  of  view. 

The  driving  topics  are  the  analysis  of  the  effects  of 
the  assessed  solutions  on  the  current  working 
practices  together  with  their  transfer  to  operational 
divisions. 


AIMS  (Eureka  Project  n.  112)  is  an  industrial 
research  project  whose  primary  objective  is  prove  the 
suitability  of  proper  software  technologies  to  provide 
adequate  solutions  to  a  number  of  problems  common 
to  the  aerospace  community. 

An  initial  Defmtion  Phase  identified  several 
categories  of  problems  currently  affecting  Aerospace 
companies  when  developing  an  Embedded 
Computing  System  (ECS).  Starting  from  this  basis, 
during  the  subsequent  Demonstration  Phase  the 
AIMS  Project  focussed  on  specific  areas  of  the 
life-cycle  to  highlight  the  nature  of  the  problems  and 
their  direct  and  indirect  consequences. 

Four  demonstration  projects  were  started,  each  of 
them  following  the  same  problem-driven  approach: 
their  goal  was  to  determine  the  impact  of  selected 
technologies  to  solve  specific  problems  identified  in 
the  previous  phase.  Expected  benefits  of  applying 
these  technologies  will  be  measured  to  provide 
acceptable  evidence  and  to  assess  their  applicability 
in  real  system  development. 

Assessment  will  be  performed  in  terms  of  quality, 
costs,  time-scale  and  co-operation  benefits.  The% 
results  are  expected  to  enable  future  aerospace 
projects,  thtd  intend  to  use  the  improved  practices  or 
sup^rt  technologies,  to  take  a  decision  about  their 
adoption  on  quantitative  basis. 


Each  assessment  will  mimic  a  real  development 
environment  dealing  with  information  from  real 
projects  -  typically  a  sub-system  from  one  of  the 
various  aerospace  projects  recently  undertaken  by 
the  companies  -  arid  it  will  directly  involve  the 
practitioners  from  the  specific  application  domaia 
The  effort  spent  during  assessmera  projects  will  have 
an  immediate  pay-back  for  all  partner  companies 
since  they  will  be  able  to  exploit  single  successfully 
assessed  technologies  on  current  projects,  even 
before  an  integrated  AIMS  solution  is  provided  in  the 
last  phase  of  the  project. 

The  Alenia  Demonstrator  is  being  carried  out  by 
Alenia  Divisione  Velivoli  Difesa  (Defence  Aircraft 
Division)  and  focuses  on  improving  practices  in  the 
area  of  software  module  testing  and 
software/software  integ.'ation  testing. 

2  THE  PROBLEM  DOMAIN 

Software  testing  is  an  expensive  and  time-consuming 
activity  in  software  development  projects  within  the 
aerospace  domain.  This  is  demonstrated  by  the  fact 
that  a  large  percentage  of  the  overall  development 
effort  is  spent  on  testing  activities:  this  percentage 
ranges  between  25%  and  50%  depending  on  the 
project  size,  complexity  and  criticality. 

The  huge  effort  spent  in  testing,  however,  is  not  paid 
back  by  a  sufficient  increase  in  the  quality  of  the  final 
product.  This  is  clearly  not  due  to  a  lack  of  effort  but 
to  the  lack  of  a  systematic  approach  to  software 
testing.  Furthermore,  while  the  management  looks  at 
testing  as  an  expensive  activity,  technical  personnel 
consider  it  as  particularly  boring.  In  addition,  it  is 
often  the  case  that  software  testing  is  sacrificed  when 
the  project  is  behind  schedule. 

A  detailed  analysis  of  the  way  of  working  within 
different  software  teams  has  confirmed  the  current 
lack  of  methods  and  tools  to  adequately  support 
testing  activities.  In  particular,  a  number  of  crucial 
problems  have  been  identified  such  as:  lack  of 
support  for  traceability  (from  requirements  to  test 
cases  specification):  lack  of  methods  and  tools  to 
verify  test  completeness  and  effectiveness;  the  test 
case  implementation  is  perfoimed  manually  which 
implies  considerable  time  and  effort  as  well  as  higher 
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probability  of  introducing  errors  and  difficulties'  in 
maintainability;  poor  support  for  test  reporting  and 
documentation.  This  list  of  problems  revealed  a 
great  need  for  improvement  of  the  current  practices 
and  a  greater  tool  support. 

The  existing  testing  policies  and  methodology 
standards  provide  some  criteria  on  how  to  perform 
and  manage  testing  activities;  however  they  define 
generally  high  level  guide-lines  about  what  items  are 
to  be  produced,  which  test  criteria  must  be  used 
depending  on  the  classification  of  the  system  under 
test,  and  so  on.  Each  company  has  to  tailor  these 
directives  to  produce  detailed  company  standards 
that  are  often  badly  implemented  within  the 
companies. 

Nevertheless,  the  testing  design  remains  mainly  an 
intuitive  process,  dependent  not  only  upon  the 
selected  testing  method  but  also  upon  the  experience 
of  the  testing  team.  It  is  still  a  problem  that  few 
developers  have  been  educated  and  trained  in  testing 
techniques. 

As  far  as  testing  tools  ate  concerned,  it  can  be  said 
that  very  few  ate  available  on  the  software  market 
compared  with  the  wide  offer  of  tools  for  other 
software  development  phases  (requirement  analysis, 
software  design,  coding).  Furthermore,  none  of  these 
tools  have  a  large  user  base,  and  -  in  the  Aerospace 
Companies  -  no  great  experience  in  the  use  of 
computer  aided  supports  has  been  found. 

It  is  clear  that  any  increase  in  the  effectiveness  of  the 
testing  process  turns  into  an  improvement  in  the 
quality  of  the  final  product  and  that  any  increase  in 
process  efficiency  results  into  an  increase  in 
development  productivity  and  into  a  C''nsiderable 
saving  in  the  overall  project  cost.  In  fact,  a  mote 
reliable  test  process  ^so  implies  a  greater  rate  of 
errors  detected  before  the  start  up  of  the  system  with 
a  consequent  increase  in  safety  confidence  and 
decreased  maintenance  costs. 

3  SOFTWARE  TESTING  TOOLS 

The  achievement  of  a  mote  cost-effective  testing 
process  is  mainly  based  on  the  application  of  a 
rigourous  testing  method  and  the  use  of  tools 
supporting  the  user  during  the  most  repetitive  and/or 
automatable  actions. 

The  use  of  testing  tools  can  drastically  reduce  the 
global  effort  and,  at  the  same  time,  it  can  provide  the 
user  a  better  understanding  of  the  performed  tests. 
This  will  bring  some  advantages  such  as  the 
reduction  of  the  manual  involvement  of  the  staff,  an 
increased  confidence  in  the  quality  of  the  product  and 
an  enhaiKed  testing  productivity.  On  the  other  hand, 
a  greater  emphasis  should  be  put  on 
education/training  in  the  testing  approach. 


In  recent  years,  an  increasing  number  of  tools 
supporting  sohware  testing  have  been  introduced  on 
the  market.  Currently  available  testing  tools  do  not 
provide  an  exhaustive  solution  to  the  whole  testing 
problem,  but  they  may  bring  considerable  benefits  to 
the  current  practices  by  supporting  a  more  systematic 
approach  to  software  testing. 

A  first  step  loward  a  more  intensive  utilization  of 
tools  in  the  testing  process  was  the  analysis  of  the 
commercial  of  the  shelf  testing  '.^ols;  this  analysis 
was  mainly  oriented  to  the  tools  supporting  test  of 
Ada  programs  and  that  are  available  on  VMS 
platform.  A  preliminary  screening  of  these  tools  has 
been  performed  based  on  commercial 
documentation.  technical  literature  and 
demonstrations. 

The  first  result  of  this  analysis  is  that  only  some 
aspects  of  the  testing  process  arc  tool-supported 
(such  as  complexity  measurement  or  coverage 
analysis)  while  some  others  critical  phases  (such  as 
test  cases  specification,  data  selection,  regression 
testing,  tracing,  reporting,  functional  coverage)  are 
manually  performed. 

Particularly  the  higher  part  of  the  testing  activities 
related  to  the  identification  of  the  functionality  to  be 
tested  from  the  Requirement  Specification  is  still 
mainly  based  on  the  tester  experience  and 
competetKC. 

The  management  of  the  testing  process  and  items  is 
another  critical  factor  that  would  require  the  adoption 
of  good  testing  practices,  the  provision  of  guide-lines 
and  monitoring  through  the  testing  process,  and  a 
good  organization  and  consistency  of  all  the  test 
items  (test  cases,  harnesses,...). 

4  ALENIA  DEMONSTRATOR 

The  thorough  analysis  of  users'  needs  described 
above,  pointed  out  that  inside  the  Aerospace 
companies  there  is  a  demand  to  improve  the  testing 
practices  and  to  increase  their  computer-aided 
support  helping  to  "simplify"  the  activities,  making 
them  more  rigourous  but,  at  the  same  time,  less 
"boring",  automating  (re-)testing  as  much  as 
possible,  and  improving  the  management  of  test 
process  and  of  the  related  information. 

This  is  expected  to  have  a  double  positive  effect.  On 
the  one  hand,  by  increasing  the  support  in  the 
execution  of  clerical  work,  it  will  relieve  technical 
personnel  from  the  most  boring  activities,  thus 
improving  the  quality  of  their  tasks  and 
consequentially  their  satisfaction.  On  the  other  hand, 
it  will  ease  the  management  of  the  whole  process, 
with  clear  advantages  for  a  crucial  part  of  the 
development  life-cycle. 


•  • 


•  • 


Within  the  AIMS  project,  the  Alenia  Demonstrator 
aimed  at  identifying  and  evaluating  a  methodology  to 
perform  effective  software  testing  in  an  efficient 
way.  Three  main  areas  where  major  improvemen  s 
are  expected  were  identified: 

•  the  exploitation  of  a  set  of  existing  commercial 
tools  that  support  specific  phases  of  the  software 
testing  process,  the  assessment  of  the  impact  of 
their  use  in  the  current  practices,  and  -  if 
successful  -  their  introduction  inside  the 
company; 

•  the  development  of  a  prototype  of  an  assistant 
tool  managing  the  whole  testing  process  and 
supporting  the  tester  during  all  testing 
activities  -  specification,  implementation, 
execution,  evaluation  and  reporting  -  as  well  as 
handling  heterogeneous  information  that  has  to 
be  produced  and  maintained  throughout  the 
testing  process; 


perform  the  different  testing  activities  and  the  quality 
of  the  tested  products,  in  terms  of  early  identified 
errors. 

4.1  Exploiting  Testing  Tools 

A  preliminary  evaluation  of  the  state-of-the-art  of  the 
tools  supporting  the  testing  of  Ada  software  was 
performed  providing  a  first  set  of  candidates  that 
could  be  introduced  in  current  practices.  Each  of 
these  tools  was  evaluated  -  on  real  case  studies  -  and 
compared  on  tlte  basis  of  a  grid  of  desirable 
characteristics  and  considering  the  effect  of  their 
introduction  in  the  current  testing  practices.  Some  of 
these  tools  were  already  available  inside  the 
company  but  not  currently  or  appropriately  used. 

The  candidate  tools  may  be  divided  into  three  main 
classes  according  to  their  functionality;  static 
analysers,  test  cases  specification  tools,  coverage 
analysers. 


•  the  assessment  of  a  formal  approach  to  test  case 
derivation  starting  from  formal  specifications  to 
help  automate  such  process. 

These  areas  of  research  address  some  of  the  most 
crucial  issues  in  software  testing  and  contribute  from 
different  perspectives  to  the  assessment  of  the 
possible  improvements  of  the  testing  process.  The 
related  solutions  will  then  be  integrated  into  a 
coherent  whole,  covering  both  methods  and  tools. 


test  specification 

test  implementation 

test  execution  | 

test  evaluation  I 

_ I 

regre>!iion  testing 


rormal  dcrivaUoii 
tcatiiig  tools 
Expert  Assistant  Tool 

Fig.1 :  Demonstrator  areas 

The  assessment  of  the  Demonstrator  is  based  on 
sub-systems  from  EFA  and  Tornado  projects  and  it 
will  provide  proof  that  the  investigated  solutions  do 
solve  the  specific  problems. 

The  extra  benefits  to  the  current  practices  will  be 
described  in  terms  of  improvements  both  in  the 
productivity  and  in  the  product  quality. 

Metrics  collection  shall  be  perfonned  during  the 
whole  demonstrator  assessment:  these  measures  will 
mainly  take  into  account  the  ^ort  required  to 


Static  analysis  consists  of  the  analysis  of  source 
code  -  without  the  need  for  any  executable  form  -  to 
determine  properties  of  programs  which  are  always 
tme  for  ^1  the  possible  execution  conditions. 
Specifically  the  purpose  is  to  verify  the  coding 
standard  conformity  and  to  measure  complexity.  The 
most  sophisticated  tools  can  also  check  the  use  of 
each  sir^e  data,  find  out  unreachable  code  and 
produce  cross  reference  of  functions  and  data. 

Test  cases  specification  implies  the  selection  of  the 
unit  to  be  tested,  the  possibly  needed  stubs 
(simulation  of  the  called  units),  the  definition  of  the 
test  driver,  the  selection  of  the  input  data  and  the 
definition  of  the  expected  output.  Test  specification 
tools  can  help  the  tester  in  these  activities  giving 
mechanisms  to  implement  test  drivers  in  an  efficient 
and  structured  way,  defining  generali2ed  stubs, 
keeping  trace  of  tests  execution  and  producing  tests 
report  The  available  commercial  tools  in  this  area 
are  either  based  on  a  test  definition  language,  or  on  a 
set  of  fimetions  embodied  in  a  programming 
language. 

Coverage  analysers  monitor  the  execution  of  tests 
and  produce  a  report  specifying  which  parts  of  the 
software  under  test  have  been  exercised  using 
particular  coverage  criteria  (statements,  bitmches, 
...). 

To  assess  and  compare  the  different  tools  (fig.  2), 
some  evaluation  criteria  have  been  defined.  They 
include  some  gene  d  aspects  of  the  tool  such  as 
supplier/vendor,  assistance,  installation,  user 
friendliness  (both  with  respect  to  learning  and  use), 
performance,  hardware/softwarc  environment 
required,  and  so  on.  For  each  class  of  tools  relevant 
characteristics  have  been  identified  which  are  related 
to  the  specific  functionality,  and  to  the  capability  to 
automatically  produce  documentation  and  test 
reports. 


♦ 
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Regression  Testing 


Fig.  2:  Evaluated  tools  classification 

Useful  indications  atwut  their  beneftts  and 
drawbacks  have  been  reported  and  a  subset  of  the 
tools  has  been  idcntined  to  activate  an 
experimentation  on  real  case  study.  This 

experimentation  led  to  the  conclusion  that  some 
testing  tools  are  matuie  enough  to  be  used  in  real 
projects  and  even  if  they  do  not  give  a  complete 
support,  it  seems  that  they  can  lead  to  relevant 
improvements. 

Alter  the  evaluation  inside  the  Atenia  AIMS  team  of 
the  most  interesting  tools,  some  tighter  cooperation 
with  the  development  teams  was  experimented  and 
gave  positive  results;  two  tools  -  TKTBED  (static 
and  dyiuonic  analyser)  and  TBGEN  (test 
specification  tool)  -  were  planned  to  be  transferred. 

The  first  step  of  the  technology  transfer  was  the 
setting  up  of  the  testing  facility  and  environment 
inside  the  testing  team,  were  the  selected  tools  have 
been  installed;  then  the  transfer  to  the  testing  team 
have  been  activated  by  means  of  training,  tutoring, 
exercises  always  supported  by  the  AIMS  team.  Such 
steps  require  not  only  qualified  resources  to  manage 
the  transition,  but  also  strong  management 
commitment  and  may  have  an  organizational  impact. 

However  the  techniques  supported  by  the  tools  do 
not  requite  specific  basic  education  and  can  be  fairly 
easily  mastered  by  average  software  personnel. 
Nevertheless  developmoit  teams  are  likelv  ’o  exhibit 
a  variable  degree  of  resistance  to  change,  especially 
where  a  tradition  about  how  to  implement  and 
execute  tests  already  exists  or  custom^ioject  tools 
and  utilities  have  been  used  for  a  long  time. 

42  Management  of  the  tesUng  process 

Test  support  is  a  crucial  problem  that  cotKems  the 
management  of  a  vast  amount  of  information  that  is 
generated,  accessed  and  maiipulated  throughout  the 
testing  process,  ranging  from  test  specification 
documents  to  software  units,  test  drivers,  reports  and 


so  on.  It  also  involves  the  definition  of  appropriate 
methods  -  as  a  way  to  perform  activities  -  and  their 
combination  within  a  testing  methodology. 

The  Demonstrator  that  iIk  Alenia  team  developed  in 
order  to  cope  with  iliese  problems  consists  of  a 
prototype  Expert  Assistant  tool  for  Testing  (EAT), 
which  addresses  two  main  aspects: 

-  the  management  of  testing  information, 

-  the  management  ol  testing  process. 

The  purpose  is  to  capture  the  knowledge  required  to 
perform  all  testing  activities  and  to  manage  all 
products  generated  by  such  activities.  The  expected 
benefits  are:  first  to  improve  testers’  productivity, 
both  by  itKieasing  the  confidence  in  what  they  are 
doing  and  by  providing  inexperienced  testers  with  a 
systematic  way  to  perform  testing;  second  to 
improve  the  product  quality. 

The  EAT  prototype  architecture  includes  an  object 
management  system,  a  knowledge  base  and  an 
advanced  human  computer  interface  (fig.  3).  It  has 
been  implemented  on  VAXA'MS  with  OSF/Motif 
using  commercial  tools  such  as  a  relational  database 
management  system  and  a  moderately  complex  but 
quite  efficient  expert  system  shell  for  the 
development  of  the  knowledge  base.  This  shell 
benefits  of  a  rule  based  language  which  provides 
Jequate  means  to  incrementally  develop  such  a 
system. 


Fig.  3:  tAT  prototype  architecture 

The  different  aspects  of  the  knowledge  related  to  the 
testing  process  model  have  been  implemented  by 
means  of  sets  of  correlated  constraints  on  the 
activities  (rules).  A  first  set  of  rules  represents 
integrity  constraints,  that  enforce  the  consistency  of 
related  objects  in  the  database;  a  second  set  includes 
process  support  rules,  which  refers  to  how  objects 
can  be  used  and  produced  by  activities.  Finally,  there 
is  a  third  set  of  rules  that  may  implement  a  given 
testing  strategy,  which  can  be  defined  at  a  project  or 
organisational  level:  these  rules  shall  be  insened  in 
the  knowledge  base  to  tailor  it  to  more  specific 
environmental  requirements.  For  instance,  the 


strategic  rules  may  enforce  a  particular  order  during 
the  test  of  the  software  units  (top-down  or 
bottom-up)  or  drive  the  user  to  perform  a  white-box 
testing  with  a  complete  structural  coverage  instead  of 
a  functional  black-box  testing.  Strategic  rules  are 
related  to  specific  project  constraints  (e.g,  criticality 
classification  or  contractual  requirements)  and  must 
be  highly  tailorable. 

Tailorability  of  the  knowledge  base  is  ordy  one 
aspect  of  EAT  configurability.  In  fact,  the  system  can 
be  interfaced  to  other  tools  that  have  to  be  used 
during  testing  (such  as  editors,  requirement 
specification  tools,  compilers  and  so  on)  according  to 
user  preference. 


The  testing  information  management  aspect 
concerns  the  storage  and  retrieval  of  all  test  items  and 
the  provision  of  an  efficacious  way  to  understand 
their  relationships  arxl  navigate  among  related  items. 
The  objects  under  test  are  seen  as  a  net  of  software 
items  (each  software  item  has  some  dependant  units 
and  depends  from  some  others  units)  and 
requirements  (relation.ships  between  software  items 
and  requirements).  This  aggregation  allows  the  user 
to  better  understand  the  structure  of  the  software 
under  test  and  find  the  functional  capabilities  related 
to  each  software  unit. 

In  a  similar  way,  the  produced  test  items  consist  of 
drivers,  stubs,  input  and  output  data,  and  so  on. 
These  items  are  stored  into  the  object  base  with  the 
links  between  them  and  with  the  objects  under  test. 

Therefore  the  user  must  be  given  a  means  to  access 
and  browse  such  information  in  a  quite  flexible  way, 
assuming  that  during  different  phases  of  the  testing 
process  (from  specification  down  to  evaluation) 
different  test  related  pieces  of  infoniiation  will  be 
relevant. 

The  functionality  provided  by  EAT  to  manage  test 
information  are  reprxxluced  and  briefly  discussed  in 
the  following: 

storage  and  browsing  of  test  items 
test  items  imported  from  a  configuration 
management  system  or  from  other  parts  of  the  user 
environment,  or  generated  while  using  EAT,  are 
stored  into  a  proper  object  base  together  with  all 
related  information  (documents,  source  code,  scripts) 
and  linked  with  other  relevant  items. 

The  user  can  browse  both  items  and  links  by  means 
of  an  advanced  human  computer  interface  where 
several  browsing  windows  can  be  opened,  one  for 
each  type  of  test  item  (e.g.  units,  specifications, 
drivers).  After  selecting  a  test  item  in  a  browser 
window,  the  user  may  ask  to  browse  all  connected 
items,  which  will  be  shown  in  other  browser 


windows,  and  so  on.  This  allows  the  user  to  display 
all  the  information  that  is  regarded  to  be  relevant  tor 
the  current  testing  activity. 

editing  and  vies^  ing  facilities  for  test  items 
the  user  can  also  display  the  textual  or  gra[^ical 
information  that  is  direedy  associated  with  each  test 
item:  after  selecting  an  item  on  a  given  browser  (e.g. 
an  input  file  for  a  test),  the  user  can  either  read  or 
modify  it  using  proper  menu  choices  on  the  browser. 
Obviously  there  are  some  pieces  of  information,  such 
as  requirements  documents  or  source  code  of 
software  units  under  test,  that  cannot  be  modified  by 
the  tester  and  whose  browsers  do  not  provide  any 
editing  option. 

informal  annotation  of  test  items 
during  various  testing  activities  the  user  is  often 
willing  to  associate  informal  notes  with  different 
items  (e.g.  to  record  test  design  or  implementation 
decisions  or  to  armotate  for  future  use);  in  common 
practice,  this  is  done  by  hand-writing  on  documents 
or  by  using  post-it  stickers.  The  system  allows  this 
kind  of  information  to  be  attached  to  each  item  by  the 
choice  of  proper  operation  offered  by  the  browsers’ 
menus;  in  the  current  version  only  textual 
information  can  be  attached,  but  provisions  have 
already  been  made  to  associate  graphical 

information. 

coverage  reporting 

to  give  the  user  the  means  to  verify  the  completeness 
of  the  performed  tests,  some  reporting  functions  have 
been  provided;  by  means  of  these  utilities  the  user 
can  see  the  percentage  of  the  units  and  requirements 
already  tested,  their  list  and  the  status  of 

completeness  of  their  related  tests. 

import  /  export  capability 

Eat  provides  a  way  to  collect  all  the  pieces  of 
information  related  to  the  software  under  test  (i.c. 
requirements,  software  units,  and  traceability 
information)  and  store  them  into  the  object  base.  For 
this  purpose  the  EAT  is  interfaced  with  a 
Configuration  Management  System  in  order  to 
retrieve  a  complete  baseline  in  a  consistent  way. 
After  the  testing  has  been  completed,  the  EAT’s 
export  capability  allows  the  user  to  store  all  test  items 
under  Configuration  Control. 

documentation 

all  testing  items  can  be  collected  and  formatted  in  an 
homogeneous  way  to  produce  a  final  Test 
Specification  Document  or  Test  Report  Document. 
The  contents  of  the  documents  can  be  tailored 
according  to  a  given  template  and  the  output  format 
can  be  chosen  between  pure  ASCII  or  specific  word 
processor  format. 
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4.2.2  Process  Management 

One  of  the  most  interesting  features  of  the  EAT  is  the 
support  it  provides  to  manage  the  testing  process. 
AiUwugh  the  testing  life-cycle  is  quite  similar  to  the 
software  development  life-cycle  and  has  a 
comparable  complexity,  it  suffers  from  a  lack  of 
formalisation,  which  makes  it  particularly  critical. 
The  knowledge  about  the  testing  process  is 
formalized  in  a  set  of  rules  that  EAT  can  use  to  drive 
the  user  to  correctly  perform  each  phases  of  testing 
both  performing  a  consistency  check  attd  suggesting 
the  user  which  activities  are  to  be  undertaken.  This 
fonnalization  has  to  take  into  account  several  factors, 
such  as  adopted  standards,  organisation  or  project 
constraints,  common  practices,  and  so  on. 

The  objective  of  capturing  this  knowledge  to  provide 
the  testing  team  with  valuable  assistance  in  a  non 
rigid  way  was  a  major  driver  of  the  Demonstrator.  A 
model  of  the  testing  process  has  been  defined  in 
temis  of  activities  and  objects  that  are  produced  by 
these  activities  in  order  to  provide  support  for 

•  guidance  -  the  model  is  used  to  provide 
assistance  and  guidance  to  the  tester.  This  means 
that  the  information  represented  in  the  model  is 
used  to  present  the  tester  the  actions  that  can  be 
performed;  and 

•  understanding  -  the  model  expresses  knowledge 
on  how  to  perfonn  the  testing  activities. 
Understanding  this  knowledge  as  early  as 
possible  may  help  the  tester  to  avoid  the 
execution  of  erroneous  activities. 

As  far  as  process  management  is  concerned,  EAT 
provides  two  kinds  of  support: 

passive  assistance 

the  system  implements  a  number  of  consistency 
checks  and  suggests  feasible  or  convenient  activities 
to  be  performed  upon  user  request,  but  it  does  not 
constrain  or  drive  the  user  in  the  way  he  /  she 
performs  such  activities. 

active  assistance 

the  system  both  monitors  the  user  during  all  activities 
and  drives  him  /  her  throughout  the  process.  This 
guidance  is  not  mandatory,  but  just  provides  the  right 
directions  to  the  user.  This  is  of  particular  importance 
when  testing  laige  and  complex  systems,  where  the 
amount  of  information  to  be  generated  and  managed 
is  fairly  relevant. 

Different  ways  of  formalising  and  managing  this 
knowledge  might  be  used,  which  are  not  based  on 
knowledge  representation  or  rule-based  paradigms 
such  as  that  adopted  in  the  EAT.  Never^less  the 
advantage  of  using  a  proper  knowledge  base  is  that  it 
can  be  easily  enhanced  or  adapted  to  specific  project 
or  organisation  needs.  Staning  from  the  basic 
knowledge  on  how  testing  must  be  performed  (i.e. 
implementing  the  standard  testing  guide-lines),  it  is 


possiMe  to  add  knowledge  that  is  more  specific  of  the 
application  domain  or  of  the  organisation  where  the 
testing  process  is  performed,  thus  capturing  testers’ 
expertise  and  capitalising  on  it. 

This  is  particularly  importam  for  test  specification 
and  implementation,  where  the  expenisc  coiKcniing 
the  applicaion  area  as  well  as  the  peculiarities  of  the 
programming  language  can  add  a  major  value  to 
these  activities.  No  other  technique  would  allow  such 
knowledge  to  be  augmented  in  a  stepwise  manner, 
thus  building  a  company-specific  "testing 
experience" 

4.2.3  Further  improvements 

Several  promising  directions  for  further  EAT 
evolution  have  been  identified  and  are  briefly 
discussed  in  the  following. 

Integration  with  external  testing  tools 
While  EAT  is  mainly  concerned  with  supporting  test 
management,  the  possibility  to  integrate  external 
tools  such  as  static  analysers,  coverage  analysers  or 
test  implementation  harnesses,  could  be  useful  and 
would  make  EAT  a  more  complete  tool. 

Integration  with  other  CASE  tools 
Some  information  managed  by  EAT  is  produced  by 
other  CASE  tools,  such  as  requirements  analysis  or 
design  tools.  It  would  be  useful  to  exploit  integration 
with  these  tools,  in  order  to  access  such  information 
in  the  right  format.  For  instaiKe,  a  CORE 
requirement  referred  by  a  test  specification  should  be 
di^ayed  by  invoking  the  CORE  tool  directly  from 
EAT  browsers,  or  the  whole  list  of  requirements 
should  be  easily  imported  inside  EAT  together  with 
the  relationships  between  requirements,  design  and 
units  code. 

Fine  grain  support 

As  mentioned  before,  the  EAT  knowledge  base  could 
be  enriched  both  by  the  knowledge  on  the  nature  of 
the  software  under  test  (functionality  and  structure) 
and  by  the  expertise  about  how  to  test  such  kind  of 
software.  This  implies  the  formalization  of  the 
previous  experience  on  testing  and  the  classification 
of  the  software  on  the  basis  of  some  paradigms,  with 
a  level  of  detail  sufficient  to  correlate  the  experience 
on  test  definition  with  each  class  of  software.  With 
this  finer  level  of  knowledge,  the  user  could  be 
supported  in  a  more  effective  way  since  the  eariy 
phases  of  testing,  and  previous  expertise  which  is 
normally  lost  after  the  end  of  a  project,  could  be 
made  available. 

4.3  Formal  Derivation  of  Test  Cases 

A  large  percentage  of  the  testing  effort  goes  into  the 
test  specification  phase  which  is  of  upmost 
importance  for  its  impact  on  the  quality  of  the  testing 
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process  itself.  In  fact,  iiinctional  testing  concerns 
checking  a  unit  or  sub-system  or  full  system  against  a 
given  set  of  specifications. 

Increasing  interest  in  fonnal  specification  techniques 
for  safety  critical  systems  and  real  time  systems  in 
general,  shows  how  the  need  for  rigourous 
requirements  fonnalisation  is  particularly  felt.  Tt  has 
been  therefore  decided  to  investigate  leasibility 
and  cost-effectiveness  of  deriving  test  specification 
from  such  formal  requirements  in  a  precise  and 
possibly  automatable  way. 

There  is  a  widespread  assumption  that  functional 
testing  is  not  required  when  using  fonnal 
specification  techniques,  because,  if  executable  code 
is  directly  and  unambiguously  derived  from  such 
specification,  the  assessment  of  correctness  can  be 
perfonned  by  means  of  fonnal  verification 
techniques. 

The  approach  taken  by  Alenia  is  a  more  pragmatic 
one:  in  fact  there  is  always  a  number  of 
non-fiinctional  requirements  (e.g.  perfonnance, 
architectural  constraints,  dependability)  that  cannot 
be  expressed  in  the  formal  specification  but  strongly 
influence  both  design  vx-  implementation  of  an 
application.  Therefore,  v/cn  if  a  full  automatic  code 
generation  were  available,  modification  of  the 
generated  code  could  be  required  anyway,  thus 
implying  the  need  for  testing. 

The  formal  specification  method  chosen  for  this 
experimentation  was  LOTOS  (Language  Of 
Temporal  Ordering  Specification),  an  ISO  standard 
for  communication  protocol  defmition  and 
conformance  testing,  currently  being  investigated 
also  by  other  AIMS  partners  companies  for 
requirements  and  design  specifications. 

4.3.1  Alenia  case  study 

The  Demonstrator  started  from  the  formal  approach 
to  systematic  test  derivation  defined  by  the  CO-OP 
method  (the  name  comes  from  the  identification  of 
compulsory  and  OPtional  tests)  which  is  applicable 
to  a  subset  of  the  LOTOS  language,  the  so  called 
basic  LOTOS. 

The  CO-OP  method  handles  neither  data 
specification  nor  variable  and  value  declaration,  but 
is  intended  to  provide  only  a  means  to  generate  test 
cases  from  the  behaviour  specification  of  a  software 
system.  The  application  of  the  CO-OP  method  to 
basic  LOTOS  specifications  allows  to  derive  test 
cases  by  means  of  merely  syntactic  manipulations 
before  they  can  be  nm  against  the  implementation  of 
the  software  system  so  as  to  verify  that  it  complies 
with  the  original  requirements  specification. 

The  method,  that  is  supported  by  a  prototype  tool 
available  from  the  LOTOSPHERE  ESPRIT  project, 
has  been  enriched  by  Alenia  AIMS  team  to  manage 
data  as  well. 


At  the  same  time,  a  requirements  subset  of  an  avionic 
sub-system  from  a  real  project  currently  undertaken 
inside  the  company  has  been  formally  specified 
using  the  formal  description  techrtique  LOTOS. 
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Fig.  4:  Avionic  system  case  study 

The  starting  point  of  this  phase  was  a  set  of 
requirements  expressed  in  a  semi-formal  notation 
(CORE  -  Controlled  Requirements  Expression)  and 
the  main  task  was  that  of  defining  these  requirements 
using  the  LOTOS  notation. 

The  case  study  development  activities  also  yielded  a 
few  general  guide-lines  to  transform  a  given  CORE 
requirements  specification  into  a  corresponding, 
semantically  equivalent  LOTOS  specification. 
These  guide-lines  define  a  mailing  from  basic 
CORE  entities  into  LOTOS  basic  entities  as  well  as  a 
mapping  between  the  essential  composition 
constructs  of  the  two  notations.  Thus,  for  instance, 
the  key  CORE  entity,  the  so  called  action,  is  mapped 
into  the  key  LOTOS  entity  called  process,  and  a 
sequence  of  actions  is  mapped  into  a  sequential 
composition  of  processes.  Moreover,  the  CORE 
mutual  exclusion  composition  construct  may  be 
represented  in  LOTOS  by  means  of  the  choice 
operator. 

The  transformation  frran  CORE  to  LOTOS  is  not 
generally  represented  by  a  one-to-one  mapping  but 
straws  some  critical  aspects,  especially  as  far  as  data 
handling  is  concerned,  in  particular,  LOTOS 
variables  may  not  be  used  on  the  left  side  of  an 
assignment  This  implies  that  values  are  lost  unless 
some  temporary  data  storage  mechanism  is  defined. 
This  particular  feature  was  realized  in  the  case  stu^ 
by  means  of  the  introduction  of  auxiliary  LOTCfe 
processes  whose  function  is  merely  that  of  acquiring 
a  data  value  and  returning  it  when  requested. 

The  availability  of  a  real  size  software  system 
LOTOS  specification  represents  the  first  step  toward 
the  evaluation  of  the  potential  of  formal  techniques 
for  rigourous  test  specification. 
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The  second  phase,  currently  under  way,  consists  of 
deriving  the  test  cases  in  a  systematic  and  possibly 
automatic  way  following  the  guide-lines  of  the 
"extended"  CO-OP  method. 


Tire  previously  mentioned  test  generation  procedure 
leads  to  the  derivation  of  a  large  number  of  test  cases. 
All  these  test  cases  can  detect  errors  in 
implementations,  and  errors  detected  with  these  test 
cases  indeed  indicate  that  an  implementation  does 
not  conform  to  its  specification.  However,  the 
number  of  test  cases  th^  can  be  generated  may  be 
very  large,  or  even  infinite.  This  implies  that  the 
execution  of  all  generated  test  cases  is  impossible,  if 
their  number  is  infinite,  unfeasible,  if  their  number  is 
very  large,  or  simply  too  expensive. 

The  reduction  of  the  number  of  generated  test  cases 
to  an  amount  that  can  be  handled  economically  and 
practically  is  therefore  rrecessary .  Such  a  reduction  of 
the  size  of  generated  test  suites  (i.e.  the  reduction  of 
the  number  of  test  cases)  by  choosing  an  appropriate 
subset  is  called  test  selection  hy  test  cases  reduction. 
Different  selection  criteria  may  be  defirred  in  order  to 
reduce  the  number  of  test  cases  once  they  have  been 
generated.  Nonetheless,  their  definition  requires 
thorough  study  and  understanding  of  the  application 
domain  and  it  may  even  vary  from  one  system  to 
another. 

Yet  another  approach  to  test  selection  may  be  chosen 
which  is  based  on  syntactical  manipulations  of  the 
original  specification.  This  approach  is  referred  to  as 
test  selection  by  specification  selection.  Instead  of 
generating  too  many  test  cases  and  then  trying  to 
reduce  their  number  a  posteriori,  this  approach  is 
intended  to  prune  the  generation  itself. 

A  further  approach  to  test  selection  was  investigated 
based  on  the  selection  of  critical  requirements  and  a 
generation  of  test  cases  for  these  requirements  only. 
This  approach  is  called  test  selection  based  on 
requirements  criticality  and,  up  to  now,  it  seems  the 
most  sensible  in  the  ff^ewoik  of  the  case  study. 

Definite  assessment  of  the  analysed  selection  criteria 
is  still  under  way,  nevertheless  a  few  indications  may 
be  given  about  tlie  initial  results.  A  full  experiment 
with  the  approach  based  on  test  cases  reduction  does 
not  seem  to  be  feasible.  In  fact  no  currently  available 
tool  supports  the  automatic  generation  of  test  cases 
for  fiiU  LOTOS  specifications  and  the  number  of 
tests  generated  applying  the  "extended”  CO-OP 
method  is  often  too  high  to  be  managed  by  hand. 

The  approach  based  on  syntactical  manipulations  of 
the  original  specification  seems  to  be  more 
promising  even  if  it  is  not  yet  mature  enough  and  a 
hnal  statement  about  its  effectiveness  cannot  be 
made. 


Finally,  the  test  selection  approach  based  on 
requirements  criticality  seems  to  be  feasible  as  well 
as  sensible.  It  is  far  more  pragmatic  than  the 
approaches  described  above  and  results  in  the 
reducikm  of  the  coverage  provided  by  the  generated 
test  suite. 


The  testing  process  and  its  activities  have  been 
particularly  neglected  by  R&D  projects  in 
information  technology,  which  are  usually  focused 
on  requirements  capturing  or  design  phases  in 
software  development. 

Unlike  many  research  projects,  where  technologies 
are  developed  for  their  own  sake  and  are 
experimented  on  small  toy  case  studies,  AIMS 
decided  to  start  from  the  real  world  requirements  and 
to  address  them  with  a  fairly  pragmatic  approach. 
This  is  also  refleaed  by  the  strong  commiunent  to 
technology  transfer,  that  is  already  happening  for  the 
first  area  of  the  Alenia  Demonstrator  (testing  tools 
exploitation)  which  is  being  transferred  into  the 
context  of  a  real  project. 

Moreover  each  area  has  a  different  impact  on  the 
testing  process.  For  instance,  while  both  the  use  of 
formal  techniques  to  derive  test  cases  and  the 
adoption  of  testing  tools  are  fairly  inuusive  with 
respea  to  the  common  practice  of  development 
teams,  EAT  is  orthogonal  to  the  process,  in  the  sense 
that  it  can  be  used  to  support  different  phases  of  the 
process,  without  imposing  particular  constraints  on 
either  practices  or  tools. 

Nevertheless  the  effort  spent  in  investigating  the 
more  advaiKed  topics  -  that  might  provide  usable 
results  in  the  longer  run  -  is  also  intended  to  spread 
the  knowledge  about  formal  specification  methods 
that  are  likely  to  become  necessary,  if  not  mandatory, 
for  future  large  programmes. 

In  conclusion,  the  AIMS  experience  turned  to  be 
particularly  important  for  Alenia.  since  intermediate 
results  were  already  transferred  to  operational 
divisions  for  everyday  use  and  an  improved 
awareness  of  both  problems  and  potential  solutions  is 
being  disseminated  across  the  whole  corporation.  We 
are  convinced  that  the  main  reason  for  this  success 
was  the  very  early  user  orientation  of  the  project, 
which  did  not  t^e  the  usual  "technology  push” 
approach,  but  spent  a  considerable  amount  of  time 
and  effort  in  understanding  the  most  important 
problems  developers  are  faced  with. 

The  relevance  of  the  Alenia  demonstrator  is  such  that 
further  exploitation  in  various  context  will  be 
considered,  starting  from  use  in  different  companies 
of  the  same  corporation. 


Discussion 


Questioa  J.  BART 

How  many  niles  did  you  have  in  EAT  rule  based  system? 

Reply 

-  100.  However,  this  number  will  be  increased  according  to  the  prototype  evolution  and  the  enrichment  of  its  knowledge 
base. 

Question  C.  KRUEGER 

What  quantitative  improvement  have  you  achieved  in  efficiency  and  produa  quality? 

Reply 

Improvements  in  testing  efficiency  and  product  quality  will  be  quantified  in  terms  of  the  effort  spent  in  the  different 
activities  of  the  number  of  (extra)  errors  found  in  the  product  Prefimi^  benefits  have  been  achieved  from  the 
testing  tools  exploitation  and  their  transfer  lo  the  operational  teams.  A  reduction  of  20%  of  the  total  testing  effort  has 
been  achieved,  even  if  some  initial  human  resistance  to  the  change  has  been  found.  Concerning  the  quahty,  some  extra 
errors  have  been  found  in  the  code,  especially  when  performing  a  complete  white-box  structural  testing  that  has 
exercised  parrs  of  the  code  never  tested  before. 
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1.  SUMMARY 

As  avionics  software  complexity  increases,  traditional 
techniques  for  avionics  software  validation  and  testing  become 
time  consuming,  expensive,  and  ultimalely  unworkable.  New 
test  issues  arise  with  the  developmenl  and  maintenance  of 
complex  "super  federated"  systems  like  that  of  the  B-2  and 
highly  integrated  systems  like  that  of  the  F-22.  Upgrades  to 
existing  weapon  systems  that  produce  a  blend  of  federated  and 
integrated  architectures  further  complicate  the  problem.  This 
paper  discusses  the  limitalians  of  current  approaches, 
equipment  and  software.  It  defines  a  next  generation  avionics 
software  validation  and  test  process,  along  with  the  hardware 
and  software  components  that  are  required  to  make  the 
process  work.  The  central  goals  of  the  process  and 
components  are  to  reduce  development  and  maintenance  costs, 
to  minimize  manpower  requirements,  to  decrease  the  time 
required  to  perform  the  testing,  and  to  insure  the  quality  of  the 
final  product  The  process  is  composed  of  unit  test, 
component  lest  configuration  item  lest  subsystem  test, 
integration  test  avionics-system  lest  and  weapon -system  lest 
Some  of  the  topics  covered  are:  automated  testing  of  avionics 
software,  real-time  monitoring  of  avionics  equipment  non- 
real-lime  and  real-time  avionics  emulation,  and  real-time 
simulation.  This  paper  is  based  upon  several  years  of 
experience  in  the  following  areas:  1)  Research  and 
development  of  new  technologies  to  improve  the 
supportability  of  weapon-system  software.  2)  Design  and 
implementation  of  facilities  for  the  development  enhancement 
and  test  of  avionics  software. 

2.  INTRODUCTION 

Testing  of  avionics  software  has  traditionally  been  a  very 
manpower  intensive  task.  For  example,  the  manual  execution 
of  the  Final  Qualification  Test  (FQT)  for  the  F-16A/B 
Expanded  Fire  Control  Computer  (XFCC)  takes  two  engineeis 
approximately  three  weeks.  Ihe  F-16A/B  Expanded  Stores 
Management  System  (XSMS)  computer  software  FQT 
requires  two  engineers  working  for  eight  weeks.  During  an 
FQT,  the  engineers  sit  at  a  simulator,  read  the  test  procedure, 
manually  execute  each  step,  and  check  for  the  correct  results. 
Checking  for  the  correct  results  can  be  as  simple  as  checking 
for  a  symbol  on  a  display  or  as  complex  as  performing  a  full 
mathematical  analysis  of  large  amounts  of  logged  data.  In  the 
past,  this  approach,  although  expensive,  worked  well  and 
produced  some  very  capable  weapon  systems.  However,  as 
the  quantity  and  processing  power  of  avionics  computers 
increases,  the  tests  tend  to  be  propralionally  more  costly  uj 
develop  and  execute.  Based  upon  the  F-16  exanqile,  a  super 
federated  system  with  over  ten  times  the  processing  capability 


of  an  F-16  could  easily  lake  many  man-months  to  test.  And, 
if  software  errors  arc  found,  as  they  ofh:n  are,  Ihe  software 
must  be  fixed  and  the  tests  run  again  from  the  begiiming.  It 
is  very  easy  u>  see  how  quickly  the  current  approach  could 
become  unworkable  and  lead  to  either  major  schedule  slips  or 
poorly  tested  software.  Highly  integrated  advanced  avionics 
results  in  even  more  test  requirements  caused  by  massive 
increases  in  software  complexity  Features  usually  associated 
with  integrated  avionics  like  system  reconfiguration  and  fault 
tolerance  are  very  hard  to  test  because  of  the  number  of 
possible  configurations.  The  only  solution  is  to  provide 
engineers  with  tools  that  enable  drastic  improvements  in 
producliviQi  throughout  the  test  process.  For  example, 
engineers  that  currently  spend  much  of  their  time  executing 
tests  should  be  able  to  concentrate  their  efforts  on  fixing 
software  jmiblems  and  creating  quality  tests.  The  uxils  should 
take  care  of  mundane  tasks,  such  as  stepping  through  a  test  or 
producing  a  lest  report.  Figure  1  illustrates  current  avionics 
testing. 


Figure  1,  Avionic*  Software  Teating 


This  paper  proposes  a  set  of  next  generation  tools  to  support 
a  test  process  for  newer  complex  weapon-system  software. 
Although  the  paper  emphasizes  testing,  it  in  no  way  intends 
to  diminish  the  importance  of  the  requirements,  design,  and 
code  generation  phases  of  software  development,  or  that  of 
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other  essential  functions  such  as  configuration  management. 
It  is  a  widely  accepted  fact  that  high  (quality  development 
during  earlier  softw  are  phases  decreases  the  number  of  errors, 
enhances  the  ease  and  quality  of  lesling,  and  potentially 
decreases  the  number  of  tests  required.  In  addition,  the 
approaches  suggested  in  this  paper  would  fail  without  a 
comprehensive  configuration  management  capability.  The 
test  process  presented  in  this  paper  is  based  generally  on  the 
Department  of  Defense  Standard  2167A  (DOD-STD-2167A). 
This  paper  identifies  key  hardware  and  software  uwls  required 
to  support  that  process.  The  process  does  not  assume  a 
specific  development  model  (i.e.,  waterfall,  spiral):  instead, 
each  test  type  is  identified  in  a  logical  sequence  from  unit  test 
through  weapon-system  test.  Also,  the  test  types  apply  to 
both  newly  developed  software  and  modifications  to  existing 
software.  The  test  types,  illustrated  in  Figure  2,  are  defmed 
as  unit  test,  component  test,  configuration  item  test,  subsystem 
test,  integration  test,  avkmics-system  test,  and  weapon-system 
tesL 


Unit  Test 


Subsystem 

Test 


Component 

Test 


rr^ 

1 

Configuration 
Item  Test 


Integration  Avionics 

Teat  System  Test 


Weapon  System  Test 


Figure  2,  Test  Types 


3.  UNIT  TEST 

Unit  test  will  be  the  first  step  in  testing  actual  code.  This 
paper  focuses  on  source  code  testing,  but  a  full  modem 
process  might  include  the  testing  of  the  requirements,  the 
design,  or  a  system  prototype  model.  Unit  test  will  be  done 
in  conjunetkm  with  code  generation,  using  an  engineering 
workstation  as  shown  in  Figure  3.  The  code  generation 
process  will  begin  after  the  detailed  software  design  is 
completed.  The  Operational  Flight  Program  (OFP)  engineers 
will  use  the  detailed  design  to  produce  each  Computer 
Software  Unit  (CSU)  and  then  test  each  unit  against  remaining 
old  requirements  and  the  new  requirements.  A  CSU  is  a 
nontrivial,  independently  testable  piece  of  code.  The  CSU 
tests  will  execute  with  automated  control  and  verificalion  and 
will  run  on  the  engineer's  woikstation  without  the  need  for  the 
target  avitmics  computer.  Code  sialysis  tools  will  perform  an 
autmnated  CSU  code  walk-through.  Necessary  revisions  will 
be  made  to  the  code  and  design  documentation,  followed  by 
any  necessary  retesting.  The  development  of  the  automated 
test  procedures  for  each  Computer  Software  Component 
(CSC)  test  will  then  begin. 


Unit  testing  requires  several  tools;  many  of  which  support 
later  stages  of  testing.  The  tools  will  be  capable  of  software 
module  test  generation,  static  code  analysis,  auiomai  d 
software  module  msung,  and  non-real-iimc  aviomcs  computer 
emulatioii.  Figure  3  illustrates  unit  test. 


•  Softwat*  Module  Teat  Genaratlon 

•  SMic  Code  Analysis 


•  Standards  Checking 

•  Code  ascrepancy  Checking 


Figur*  3,  Unit  T*st 


3.1  Software  Module  Test  Generation 

The  goals  of  software  module  lest  generation  are  to  produce 
a  test  that  validates  compliance  with  all  the  requirements 
allocated  to  the  module,  and  to  insure  traceability  between  the 
requirements,  the  design,  the  software  module,  and  the 
specific  tests.  The  word  “module "  applies  to  a  CSU,  a  CSC, 
or  a  Computer  Software  Configuration  Item  (CSCl).  The  tool 
will  list  the  module  requirements  and  provide  assistance  in 
creating  the  tests.  Creating  the  tests  will  involve  creating 
tables  of  input  data  and  corresponding  expected  output  data. 
Entering  and  calculating  the  data  required  for  module  testing 
can  be  very  time  consuming  and  error  prone.  Consequently, 
the  interface  to  the  software  module  test  generation  will  be 
similar  to  a  spreadsheet  where  data  can  be  entered  in  large 
quantities,  based  on  pattern  sequences  and  formulas. 

3.2  Sialic  Code  Analysis 

Static  code  analysis  has  not  been  traditionally  a  part  of  the 
OFP  test  process  because  appropriate  tools  have  not  been 
available,  especially  for  programming  languages  used  in  OFPs 
such  as  JOVIAL.  Software  technological  advances  and  more 
recent  high  order  languages  like  Ada  have  brought  about  more 
stalk  analysis  tools.  Static  test  tools  can  perform  such 
functions  as  identifying  coding  errors,  like  code  that  cannot  be 
executed  (i.e..  dead  code),  insuring  conformance  to  coding 
standards,  identifying  complex  portions  of  code  that  may 
require  special  test  attention,  and  suggesting  a  design  change 
to  improve  code  quality  and  supportability.  A  few  static 
analysis  tools  capable  of  test  support  are  listed  below. 
Increased  statk  code  analysis  capability  is  expected  in  the 
future.  Statk  code  analysis  will  include  standards  checking, 
code  discrepancy  checking,  and  software  complexity  analysis. 
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3.2.1  Standard!  ducking 

Standards  checking  will  validate  the  compliance  of  the 
developed  source  code  with  the  project  programming 
standards  and  guidelines.  Standards  checking  will  include  a 
review  of  naming  conventions,  module  size,  frequency  of 
cranments,  readability,  etc.  A  detailed  report  will  list  any 
deviations  from  the  standards. 

3.2.2  Code  Ducrtpancy  Checking 

Code  discrepancy  checking  will  identify  potential 
discrepancies  in  the  code:  i.e.,  code  that  caimot  be  executed, 
variables  that  are  declared  but  never  used,  and  control  flow 
that  has  a  single  path  (i.e..  if  1<2  then  ...).  In  addition  to 
identifying  quality  and  efficiency  problems  in  the  code, 
discrepancy  checking  will  identify  potential  errors  by  drawing 
attention  to  portions  of  the  code  that  may  contain  errors. 

3.2.3  Software  Complexity  Anahsis 

Software  complexity  analysis  u-ill  evaluate  source  code  for 
complexity.  The  tools  will  analyze  the  source  code  using 
complexity  metrics  such  as  that  of  McCabe  and  Halstad.  The 
tools  will  identify  portions  of  code  that  are  potentially  too 
complex  for  complete  testing  and  cost-effective  maintenance. 

3.3  Automated  Software  Module  Testing 

Unit  testing  has  always  been  labor  intensive.  The  basic 
problem  is  the  fact  that  units  are  usually  embedded  in  a  larger 
body  of  software.  The  tasks  of  separating  out  each  unit, 
writing  the  required  test  driver  software  for  each  CSU,  and 
executing  the  test  are  ^  ery  manpower  intensive.  In  addition, 
a  lot  of  software  is  produced  that  will  eventually  be  discarded. 
An  automated  software  module  test  tool  will  extract  units 
from  the  existing  software  based  on  comments  in  the  code, 
generate  the  lest  shell,  execute  the  lest,  and  repmt  the  results. 
The  report  will  include  general  information  on  the  unit  that 
was  tested,  the  test  that  was  executed,  the  results  of  the  test, 
and  the  test  coverage  analysis.  The  coverage  analysis  will 
help  the  engineer  to  understand  how  comprehensive  a  lest  is 
by  identifying  the  number  of  times  each  line  of  code  is 
exercised  during  the  test.  As  software  development  continues, 
the  tool  will  maintain  a  log  of  tested  units  and  input  lest  data. 
The  logged  information  will  then  be  used  to  indicate  which 
unit  tests  need  to  be  repeated  due  to  changes  in  the  unit  code 
or  changes  in  the  unit  test  data.  An  OFP  developer  will  make 
modifications  to  the  software  and  then  invoke  an  automated 
unit  ust.  The  automated  unit  test  tool  will  then  identify  all 
units  that  need  to  be  tested  and  execute  the  tests.  New  units 
without  test  data  will  be  idenuTied  U}  the  user. 

3.4  Nan-Real-Time  Avionics  Computer  Emulation 

A  non-real-time  emulaurr  hosted  cm  the  engineer's  workslaticm 
will  support  the  executkm  of  automated  tests.  The  emulator 
will  provide  an  instruction  set  simulator  for  the  target 
prcxiessor,  simulation  of  ail  the  hardware  that  the  software 
communicates  with,  and  a  full  interactive  debugging 
capability.  The  debugger  will  provide  visibility  into  the 
execution  and  data  values  of  the  software  module  under  test 
It  will  support  assembly  language  or  high  order  language 
"views"  of  the  software.  The  emulator  will  also  (noduce  a 
variety  of  calculated  estimaies  of  the  execution  characteristics 
of  the  software  running  cm  the  actual  avionics  computer, 
including  memory  requirements  and  executkm  timing. 


4.  COMPUTER  SOFTWARE  COMPONENT  TESTING 
The  Computer  Software  Component  (CSC)  testing  will  begin 
after  the  coding  and  CSU  testing  have  been  completed.  The 
CSC  testing  will  insure  that  the  algorithms  and  logic  are 
correct  aitd  that  the  CSC  satisfies  its  allocated  requirements. 
DOD-STD-2167AS  CSUs.  CSCs,  and  CSCls  imply  that 
software  can  be  broken  mu>  three  logical  levels.  In  practice, 
the  number  of  component  levels  should  reflect  the  complexity 
of  the  software.  Tests  should  be  executed  according  to  the 
requirements  of  each  level.  Therefore,  CSC  testing  will 
include  testing  groups  of  CSCs  in  addition  to  groups  of  CSUs 
fanning  a  CSC.  All  the  CSC  testing  will  be  performed  on 
workstations  using  non-real-time  avionics  computer  emulators 
and  automated  software  module  testing.  Corrections  to  the 
code  will  result  in  revisions  u>  the  documenution,  retesting, 
and  updates  to  the  configured  CSU  and  CSC  source  files.  A 
code  analysis,  assisted  by  aulomaied  tools,  will  be  performed 
on  any  code  that  has  been  revised.  The  CSCl  automated 
software  module  tests  will  then  be  developed  and  checked  for 
completeness  and  accuracy. 

Due  to  the  strong  similarity  between  CSU  and  CSC  testing, 
CSC  testing  will  use  all  of  the  tools  used  in  CSU  testing, 
including  software  module  test  generation,  static  code 
analysis,  automated  software  module  testing,  and  non-real¬ 
time  avionics  computer  emulation.  However,  CSC  testing  will 
place  additional  demands  on  the  tools  identified  in  section  3. 
The  new  requirements  include  support  for  multiple  levels  of 
testing  and  support  for  software  physically  located  in  multiple 
files.  No  new  tools  will  be  required  to  support  CSC  tests. 
Figure  4  illustrates  CSC  testing. 


•  Software  Modul*  Teat  Ganaration 

•  SUlic  Coda  Analysis 

•  Standards  dwcUng 

•  Code  Discrepancy  Checking 

•  Software  Complexily  Analysis 

•  Automated  Software  Module  Testing 

•  Mnn  Riail  Tlmn  Avionics  Computer 
Emulation 


Figure  4,  Component  Test 

5.  COMPUTER  SOFTWARE  CONFIGURATION  ITEM 
TESTING 

The  Computer  Software  Configuration  Item  (CSCI)  testing 
will  begin  when  CSC  testing  is  complete.  The  Operational 
Flight  Program  (OFP)  engineer  will  produce  a  full  CSCI  load 
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module  and  execuie  it  on  die  worksudon,  using  a  non-real- 
cane  avionics  coni|»UBT  emulator.  The  goals  of  CSCI  testing 
will  be  to  insure  that  all  the  components  function  together, 
and  to  verify  that  the  interface  to  other  CSCb  is  in  accordance 
with  the  interface  design  document.  To  reduce  equipment 
costs,  the  test  will  be  conducted  on  a  workstation  rather  than 
on  the  more  expensive  avionics  computer.  Depending  upon 
the  relative  processing  capability  of  the  actual  avionics 
computer  and  the  workstation  executing  the  emulation,  the 
utility  of  this  stage  of  testing  may  vary.  If  the  execution  of 
the  workstation  emulation  is  excessively  dme  consuming,  then 
this  testing  can  be  done  during  subsystem  test  The  non-real- 
time  avionics  computer  emulator  will  have  full  CSCI  debug 
capability  that  will  include  monitor  and  control  of  the  CSCI 
execution  and  its  data.  Automated  module  testing  software 
will  provide  test  data  to  the  CSCI  and  then  verify  that  the 
corresponding  CSCI  output  data  is  correct  The  tests  will  be 
performed  and  the  results  recorded  in  the  software  test  report. 
Revisions  to  documentation  or  code  and  retesting  of  the 
CSUs,  CSCs,  and  CSCI  will  be  directed  by  the  results  of  this 
workstation-based  testing. 

The  CSCI  testing  will  use  many  tools  used  earlier  in  CSU  and 
CSC  testing.  These  tools  include  software  module  test 
generation,  static  code  analysis,  automated  software  module 
testing,  and  non-real-time  avkmics  computer  emulation.  No 
new  tools  will  be  required  to  support  CSCI  tests.  Figure  3 
illustrates  configuration  item  testing. 


Hgur*  5,  Configuration  Itam  Teat 

6.  SUBSYSTEM  TESTING 

Subsystem  testing  begins  after  the  workstation-based  CSCI 
testing  phase  has  been  completed.  During  subsystem  testing, 
the  OFF  engineer  will  use  a  test  station  to  load  the  actual 
OFP(s)  into  the  avionics  subsystem  hardware.  This  will  be 
the  first  time  that  the  new  software  will  be  executed  cm  the 
actual  avionics  hardware.  Therefore,  these  tests  will  focus  on 
software  integration  with  the  hardware  and  include  tests  of 


external  communication  with  other  subsystems.  Subsystem 
testing  will  be  performed  with  both  statically  and  dynamically 
generated  data. 

Internal  interactiem  and  basic  external  interface  testing  will  be 
initially  perfonned  using  statically  generated  dau.  The 
subsystem  will  be  stimulated  with  specific  inputs  and  the 
outputs  will  be  verified.  Inputs  to  the  subsystem  will  be 
produced  from  pre-generaied  data,  and  then  during  execution, 
the  inputs  will  be  driven  by  the  real-time  requirements  of  the 
subsystem.  The  outputs  will  be  monitored  in  real  time  and 
verified  for  correemess.  Dependmg  upon  the  particular 
subsystem,  the  mputs  and  outputs  can  take  a  variety  of  forms 
(e.g.,  discrete  data,  serial  digital  data,  parallel  digital  data, 
analog  data,  and  Radio  Frequency  (RF)  data).  Complete 
computer  control  of  the  intcrfaces/deviccs  that  produce  and 
monitor  the  inputs  and  outputs  will  be  provided.  In  addition, 
the  OFF  engineer  will  have  full  real-time  monitor  and  ctmtrol 
capabilities  over  the  subsystem  compulerfs).  With  these 
capabilities,  the  OFF  engineer  will  be  able  to  initiate 
stimulaticHi  of  the  subsystem,  monitor  the  response,  and 
observe  the  execution  of  the  software.  Thus  the  OFF  engineer 
will  be  able  to  verify  conformance  m  mterfacc  requirements, 
check  the  basic  operation  of  the  software,  and  isolate  any 
discrepancies  in  the  software. 

The  second  level  of  testing  will  be  fully  dynamic  and  scenario 
oriented.  The  environment  externa]  to  the  weapon  system  will 
be  simulated,  and  the  various  avionics  that  communicate  with 
or  produce  data  for  the  subsystem  will  also  be  simulated.  The 
simulated  environment  together  with  the  simulated  avionics 
will  provide  a  fully  interactive,  real-time  environment  by 
supplying  data  to  and  from  the  real-time  :.ubsyslem  interface. 
The  subsystem  will  be  "flown"  through  various  scenario'  in  a 
realistic  controlled  environment  that  will  exercise  the 
subsystem  software  in  a  variety  of  dynamic  conditions.  The 
tests  will  be  specifically  designed  for  the  subsystem  under 
test.  The  test  station  simulation  and  real-time  avionics 
monitor  and  control  capability  will  be  used  either  manually  or 
automatically  to  execute  tests,  to  verify  correct  operation,  and 
to  isolate  any  discrepancies  in  the  software.  The  relative 
magnitude  of  the  tests  done  using  statically  generated  data 
verses  those  done  using  dynamically  generated  data  will 
depend  iqxm  the  operational  function  of  the  subsystem  under 
test.  Subsystems  with  more  dynamic  functions  such  as 
weapon  delivery  or  target  tracking  will  require  more  dynamic 
testing.  Subsystems  like  weapon  stores  management  and 
displays  will  be  likely  to  require  more  tests  using  statically 
generated  data.  After  both  subsystem  test  types  have  been 
accomplished,  the  results  will  be  recorded  in  a  software  lest 
report  Any  revisions  to  documentation  or  code  and  retesting 
of  the  CSUs.  CSCs,  and  CSCls  will  be  based  on  the  results  of 
the  subsystem  level  testing. 

It  is  important  to  note  that  there  will  be  (and  there  currently 
are)  two  distinct  types  of  OFF  engineers  executing  the  tests: 
the  OFF  developer  and  the  OFF  tester.  Each  type  will  have 
a  different  view  of  testing  and  different  requirements  for  test 
support  tools.  The  OFF  developer  will  write  the  software  and 
will  conduct  initial  tests.  This  function  will  require  extensive 
monitoring  of  both  the  execution  of  the  OFF  undergoing 
testing  and  the  test-station  data  stimulating  the  OFF.  While 
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the  OFP  is  executing  in  (he  avionics  computer,  the  OFP 
developer  will  need  extensive  interactive  debugging 
capabilities  at  both  the  assembly  language  level  and  in  the 
high  order  language  symbols  and  statements.  The  OFP 
developer  will  focus  on  the  software's  behavior  as  it  executes 
internally  in  the  avionics  compuusr.  This  approach  is 
sometimes  called  "white  box  testing."  The  tests  will  range 
from  unit  to  avkmics-system  tests.  Some  testing  will  be 
automated;  however,  many  tests  will  be  highly  interactive  as 
new  functions  are  checked  and  problems  are  found  and 
isolated. 

OFP  testers  will  usually  be  managerially  independent  of  the 
OFP  developers  and  will  have  a  different  test  focus.  The  OFP 
tester  will  treat  the  avionics  computer  and  software  like  a 
"black  box"  that  will  be  expected  to  provide  certain  functions. 
The  OFP  tester  will  focus  on  exercising  the  avionics  computer 
in  many  different  modes  and  scenarios  to  insure  that  it  will 
function  according  Ui  its  requirements.  A  primary  interest  of 
the  OFP  tester  will  be  the  automation  of  the  lung  and 
monotonous  forma]  tests.  Automating  the  tests  will  also 
permit  the  OFP  tester  to  design  and  perform  more 
comprehensive  tests.  The  OFP  tester  will  perform  manual  and 
automated,  subsystem,  integration,  and  avionics-system 
testing. 

During  subsystem  testing,  OFP  developers  and  testers  will 
use  numerous  hardware  and  software  tools.  These  tools  will 
also  support  integration  testing,  and  some  will  support 
avionics-system  testing  and  weapon-system  testing,  as  well. 
These  tools  include  a  Virtual  Test  Station  (VTS),  OFP  test 
dau  generation,  OFP  test  dau  driver,  test  case  generation, 
automated  real-time  testing,  data  monitor  and  control,  and 
real-time  avionics  computer  emulation.  Figure  6  illustrates 
subsystem  test. 


•  virtual  Teat  Station 

•  OFP  Test  Data  Ganaralion 

•  OFP  Taat  Data  Oitvnr 

•  Teat  Caaa  Generation 

•  Automated  Real-Time  Teatbig 

•  Data  MonMor  and  Control 

•  Simulation  and  Stlmulallon  Monitor  and  Control 

•  Avionics  Communicallon  and  Marfaee  MonMor  and  Control 

•  Avionics  Computer  MonMor  and  Control 

•  Real-Time  Avionics  Computer  Emutetlon 

Figure  6,  Subsystem  Test 

6.1  Virtual  Test  Station 

When  aircraft  had  only  one  or  two  embedded  computers, 
avionics  software  was  traditionally  supported  by  an  avionics 
test  station  (sometimes  called  a  "dynamic  test  stand"  or  an 
"integration  support  station").  The  lest  station  simulated  all  of 
the  necessary  subsystems  in  real  time,  provided  stimulus 
signals  to  an  avionics  computer  running  the  software  under 
test,  and  monitored  and  recorded  outputs  produced  by  the 
software.  The  test  suition,  which  was  custom  built  for  each 
type  of  avionics  computer,  had  a  large  simulation  computer 
that  performed  the  real-time  computation.  Complex,  special- 
purpose  interfaces  provided  stimulus  and  monitoring  signals 
for  the  avionics  computer.  These  systems  were  very 


expensive  U3  develop,  and  were  also  found  to  be  very 
expensive  w  enhance  and  maintain.  For  aircraft  w  ith  only  a 
few  avionics  computers,  this  approach  was  viable,  but 
inefficient.  For  modem  aircraft  with  many  avkmics 
computers,  large,  monolithic,  dedicated  lest  stations  are  no 
longer  practical.  The  future  requires  us  to  break  this  cycle  of 
building  large,  dcdicau»l  test  stations  for  each  avionics 
computer,  and  to  develop  a  collection  of  modular,  generic 
components  from  which  tesi  stations  can  be  assembled  easily 
and  economically.  By  emphasizmg  flexibiUty,  exlendibility 
and  reusability  in  the  design  of  the  uisl  station  architecture  and 
components,  the  same  set  of  components  will  be  able  u> 
siq^iort  software  on  multiple  avionics  compuuirs. 

In  addition  to  lowering  cost  and  increasmg  flexibility .  other 
avionics  support  requirements  are  emerging  due  to  super 
federated  and  mlegrated  avionics  systems.  As  avionics 
systems  become  more  mtegrated,  the  support  systems  that  will 
be  used  to  test  the  avionics  software  and  hardware  will  need 
to  be  mate  integrated.  Early  in  the  development  of  avionics 
software,  the  work  will  focus  on  individual  avionics 
subsystems  in  isolation.  As  development  progresses,  more  of 
the  actual  avionics  subsystems  w  ill  be  incrementally  integrated 
until  the  entire  avionics  suite  is  complete.  The  engineers  will 
need  a  test  station  that  allows  them  to  work  on  mdividual 
subsystems  independently  without  interfering  with  others. 
Then,  when  they  are  ready  u>  integrate,  they  will  need  a  test 
system  that  can  be  easily  reconfigured  to  incorporate  any 
number  of  the  other  subsystems  required  for  a  lest.  The  VTS 
will  address  these  issues. 

The  VTS  will  be  a  complehsly  reconfigurable  avionics  support 
system.  The  reconfiguration  will  be  controlled  through 
software,  thus  permitting  rapid,  easy  changes  uj  the  test 
system.  It  will  reconfigure  to  support  a  variety  of  tests  using 
various  combinations  of  avionics  hardware  and  software 
Working  from  either  a  worksuiion  or  a  lest  console,  an  OFP 
engineer  will  use  the  VTS  to  configure  a  lest  station  wiih  the 
required  avionics  hardware  and  siniuiauon  software  to  support 
a  particular  test  With  the  VTS,  permanent  individual  test 
stations  will  not  exist  The  support  environment  will  consist 
of  a  collection  of  hardware  and  software  building  blocks  that 
can  be  conEgured  to  produce  exactly  the  test  station 
configuration  required  for  any  given  lest.  The  VTS  will 
contain  workstations,  test  consoles,  avionics  computers, 
avionics  computer  interfaces,  avionics  computer  stimulation 
equipment,  avionics  computer  monitors  and  controllers,  and 
general  purpose  real-time  processors.  The  VTS  will  include 
a  combination  of  models,  avionics  emulauirs,  and  actual 
avionics  hardware,  which  will  provide  the  environment  for  the 
avionics  subsystem  under  test  and  exercise  it  in  various 
scenarios.  The  VTS  will  be  capable  of  performing  tests  with 
one  actual  avionics  subsystem  and  the  other  avionics  and 
external  environment  simulated.  It  will  also  perform 
integration  testing  (discussed  in  section  7)  with  multiple  actual 
avionics  subsystems,  while  simulating  the  remaining  avionics 
and  the  external  environment.  Assuming  there  are  sufficient 
resources  within  the  VTS,  it  will  support  many  lest  stations  in 
various  configurations,  all  operating  simultaneously.  When  a 
specific  component  of  the  VTS  is  not  in  use.  it  will  be 
available  from  the  pool  of  "VTS  resources  to  be  allocated  and 
used  as  part  of  a  lest  station.  This  will  allow  maximum  use 
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of  die  coitly  avionics  and  simulation  resources.  In  addition, 
OFF  engineers  will  have  access  to  (he  hardwue  and  software 
needed  K>  perform  any  test  Figure  7  illusiraies  the  VTS 
resources. 

The  VTS  concept  provides  many  interesting  possibilities. 
From  the  perspective  of  the  OFF  engineers,  it  will  be  possible 
to  select  exactly  the  resources  or  resource  types  needed  for  a 
particular  test  From  a  test-station  maintenance  perspective, 
it  will  be  possible  to  take  various  resources  "off-line"  for 
maintenance  without  impacting  the  use  of  the  other  resources. 
If  a  resource  fails  while  allocated  to  a  particular  user,  the  user 
will  simply  take  that  resource  off-line,  replace  it  with  an 
equivalent  resource,  and  then  alert  the  maintenance 
organization.  From  the  test-station  management  perspective, 
the  VTS  concept  will  significantly  reduce  the  cost  of  building 
and  maintaining  a  full  avionics  software  support  facility. 
Since  test  station  resources  will  not  be  permanendy  conTigured 
in  a  VTS  facility,  more  efficient  use  of  a  smaller  aggregate 
number  of  resources  will  provide  the  same  effective  testing 
capacity  as  a  larger,  more  expensive,  traditional  facility.  This 
will  reduce  initial  acquisition  costs  and  life-cycle  costs.  Also, 
to  optimize  use  of  VTS  resources,  the  VTS  resource  allocation 
will  be  automatically  monitored  to  determine  when  more 
resources  are  required  to  support  the  work  load,  and  when 
existing  resources  are  not  utilized  and  can  therefore  be 
eliminated. 

For  more  information  on  the  VTS,  reference  "Virtual  Test 
Station"  by  Steven  A.  Walters  of  Science  Applications 
International  Corporation  (SAIC)  and  Mark  M.  Stephenson  of 
the  United  States  Air  Force,  a  paper  presented  at  the  National 
.\crospace  and  Electronics  Conference  (NAECON),  May  24- 
28,  1993. 


4.2  OFF  Teal  Data  Gaacraltoa 

The  goals  of  OFF  test  data  generation  are  similar  to  those  of 
software  module  lest  generation;  i.e.,  to  produce  a  test  that 
validates  compliance  with  the  requirements  allocated  to  the 
subsystem  software,  and  to  insure  traceability  between  the 
requirements,  the  design,  the  subsystem  software,  and  the 
specific  tests.  Test  data  will  be  generated  for  requirements 
that  can  be  adequately  and  practically  validaied  with  statically 
generated  data.  The  test  generation  will  focus  on  defining  the 
stimuluion  data  with  its  associated  timing  reqiurements.  along 
with  expected  response  data  and  tuning.  The  specific 
stimulation  and  response  data  types  will  depend  upon  the 
subsystem  under  test.  Many  subsystems  now  communicate 
using  the  Military  Standard  IS53B  fMIL-STD-1553B)  bus. 
analog  signals,  and  discrete  signals,  (hher  subsysutms  may 
require  and/or  generate  RF  or  optical  signals.  Entering  the 
raw  data  to  control  and  monitor  these  signals  can  be  very  time 
consuming  and  error  prune.  Consequently,  the  interface  for 
test  data  generation  will  be  similar  to  a  spreadsheet  where 
data  can  be  entered  in  large  quantities,  based  on  pattern 
sequences  and  formulas.  Timing  will  be  defined  usmg  various 
options;  e.g..  a  function  of  time,  a  function  of  the  avionics 
computer's  major  processing  cycle,  and  a  function  of  the 
demand  of  the  avionics  and  stimulation  hardware 

4.3  OFF  Test  Data  Driver 

The  test  data  driver  will  be  similar  to  the  automated  software 
module  test  loot  but  will  have  some  important  differences. 
The  test  data  driver  will  control  the  VTS  and  drive  a  sequence 
of  real-time  data  to  produce  actual  mput  signals  to  the 
avionics.  In  addition,  the  test  data  driver  will  check  the  real¬ 
time  output.  For  example,  the  M1L-STD-1553B  bus  will  be 
driven  with  realistic  data  and  the  M1L-STD-ISS3B  response 
will  be  checked  for  correctness.  Timing  of  the  input  data  and 
the  responses  is  critical,  and  in  fact,  the  measurement  of  the 
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Figure  7,  Virtual  Teat  Station  (VTS)  Resources 


lime  between  events  will  be  one  of  the  lest  options.  A  report 
will  be  gen^Med  by  the  OFP  lest  data  driver  that  will  include 
general  information  on  the  OFP  that  was  tested,  the  particular 
lest  that  was  executed,  and  the  results  of  the  u;sl 

6.4  Test  Case  Generation 

The  goals  of  the  test  case  generation,  like  those  of  the 
software  lest  dau  generation,  are:  to  produce  a  lest  that 
validates  compliance  with  the  requirements  allocated  to  the 
subsystem  software,  and  to  insure  traceability  between  the 
requirements,  the  design,  the  subsystem  software,  and  the 
specific  tests.  Test  case  generation  will  be  used  to  create 
automated  test  procedures  that  can  be  adequately  and 
practically  validated  with  dynamic  scenario-oriented  testing. 
Test  cases  will  be  written  in  a  procedure-oriented,  structured, 
english-like  language  that  can  be  easily  understood  by  a  test 
engineer.  The  test  case  generation  tool  will  be  "language 
sensitive"  with  features  like  automatic  syntax  checking  and 
mouse-driven  selection  of  language  constructs  and  key  words. 
The  tool  will  have  a  graphical  representation  mode  to  provide 
the  user  with  a  "picture"  of  the  total  test  flow.  Since  the 
complexity  of  the  software  is  increasing  drastically,  the 
generation  of  quality  tests  is  becoming  increasingly  complex. 
The  lest  case  generator  will  provide  a  variety  of  techniques  to 
support  automatic  generation  of  test  sequences. 

The  test  case  language  will  support  the  full  representation  and 
automation  of  the  actual  test  and  validation  procedures.  The 
test  language  will  also  have  provisions  for  the  execution  of 
special  debug  tests  to  isolate  problems  found  by  the  test.  The 
test  language  will  include  a  variety  of  constructs  including:  1) 
command  file  structuring;  i.e.,  including  other  command  flies 
and  defining  subroutines,  2)  simulator  set  up  and  control;  i.e., 
selecting  the  simulation  configuration,  loading  initial 
conditions  and  stopping  the  simulation,  3)  user  control;  i.e., 
turning  a  cockpit  panel  knob,  or  flying  the  aircraft,  and  4) 
validation  and  analysis;  i.e.,  checking  that  a  cockpit  light 
comes  on  or  that  a  MIL-STD-15S3  packet  contains  certain 
data,  or  checking  a  set  of  logged  data  for  a  given 
mathematical  relationship. 

6.5  Automated  Real-Time  Testing 

The  automated  real-time  test  software  will  "fly"  the  simulator 
through  the  test  scenario  and  perform  the  appropriate  tests.  If 
discrepancies  arc  found,  appropriate  actions  will  be  taken  and 
the  problem  will  be  logged  to  a  test  report  file.  Since  the  test 
command  language  will  permit  the  automatic  selection  and 
configuration  of  VTS  resources,  tests  scheduled  for  execution 
after  hours  will  be  able  to  automatically  allocate  the  required 
VTS  resources,  execute,  and  then  deallocate  the  resources. 
According  to  estimates  based  on  prototyping  portions  of  actual 
tests,  automated  real-time  testing  will  effectively  increase  the 
total  test  case  execution  speed  by  over  100  limes.  Figure  8 
illustrates  automated  real-time  testing. 

In  addition,  a  potentially  very  valuable  test  technique  will  be 
made  possible  by  the  capability  of  fully  automated  real-time 
testing.  As  avionics  software  becomes  more  sophisticated,  the 
number  of  paths  through  the  software  drastically  increases.  It 
would  take  many  years  to  go  through  every  possible  software 
combination  on  even  a  current  generation  weapon  system. 
Instead,  tests  today  are  developed  to  test  major  functions  in 
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the  software.  Only  exDemely  critical  functions  such  as 
nuclear  weapon  delivery  have  very  extensive  tests.  However, 
if  an  automated  real-time  test  capability  can  operate  totally 
without  user  intervention  and  simulators  can  be  produced  at 
minimum  cost,  then  u»ling  could  occur  in  two  phases.  The 
first  phase  would  include  the  basic  critical  tests  that  arc  done 
now.  The  avionics  software  could  then  be  released.  The 
second  phase  would  be  an  exhaustive,  random  test  that  would 
run  continually  (or  whenever  the  simulation  resources  are  idle) 
fur  the  life  of  the  software  version.  The  goal  of  this  uist 
would  be  to  And  any  unique  combinauon  of  circumstances 
that  exposes  a  software  problem.  If  a  major  problem  were 
found,  an  emergency  cutrecliun  could  be  made.  If  the 
problem  were  minor  then  the  correction  uiuld  be  meorpurated 
into  the  next  version  of  the  software. 

6.6  Data  Monitor  and  t'antrol 

Real-time  data  monitor  and  control  is  a  critical  function  m 
both  debugging  and  validatmg  avionics  software.  The  OFP 
engineers  need  to  know  exactly  what  information  ts  gotng  m 
and  out  of  the  subsystem  under  test,  and  they  need  to  monitor 
the  execution  of  the  software  in  order  to  either  find  software 
problems  or  demonstrate  its  correemess.  The  OFP  engineers 
also  need  the  capability  to  modify  data  in  real-time  to  create 
unique  situations;  i.e.,  corrupt  communication  data,  and 
failures.  Data  monitoring  and  control  can  be  extremely 
complex.  Test  stations  and  avionics  produce  large  quantities 
of  data  at  very  high  rates,  making  storage  of  all  the  daU 
impractical.  Also,  the  data  that  is  produced  m  multiple 
locations  (e.g.,  avionics  subsystem,  simulation)  must  be 
synchronously  controlled  and  monitored,  and  then  ci'rrelaled, 
in  order  to  provide  information  on  the  entire  system.  A 
common  data  time  lag  will  be  used  to  merge  and  analyze 
system-wide  data.  Finally,  it  is  generally  unwise  to  slop  or 
delay  the  simulation  and  avionics  to  obtain  data.  Real  time 
systems  (especially  avionics)  often  change  state  when  they  are 
hailed,  and  they  cannot  always  be  restarted  at  the  point  from 
which  they  were  hailed. 

Data  monitoring  will  include  multiple  alphanumeric  and 
graphical  color  display  types  m  present  the  information  in  a 
format  that  can  be  quickly  interpreted.  A  common  user 
interface  for  both  monitor  and  control  will  be  independent  of 
the  source  of  the  data  and  of  any  special  hardware  and 
software  that  might  be  required  to  modify  or  obtain  the  data. 
Also,  multiple  Altering  and  data  event  triggering  functions  will 
reduce  the  time  and  effort  required  to  understand  the  data  and 
to  compare  it  against  expected  results.  Three  primary 
functions  are  required  for  data  monitoring  and  control:  1) 
simulalion/stimulatian  moniuir  and  control.  2)  avionics 
communication  and  interface  monitor  and  control,  and  3) 
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avicnics  processing  monilur  and  control  Figuie  9  Ulusliales 
the  three  types  of  monitor  and  control. 
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FIgur*  9,  Monitor  and  Control  Typoa 

6.6.1  SimulatiOHlStimuialioK  Monitor  and  Control 

In  an  automated  or  manual  test,  the  test  engineer  requires  full 
access  to  the  simulation  and  avionics  stimulation  data  to 
know,  in  detail,  the  environment  provided  for  the  subsystem 
under  test.  The  test  engineer  also  needs  to  be  able  to  control 
the  environment  to  generate  various  tests.  The 
simulation/stimulation  monitor  and  control  will  allow  the 
manual  or  automatic  user-specified  monitoring,  logging,  and 
controlling  of  simulation  and  stimulation  functions  and  data. 

6.6.2  Avionics  Communication  and  Interface  Monitor  and 
Control 

Most  avionics  computers  have  multiple  digiul  and  analog 
interface  signals  to  send  or  receive  information  from  other 
avionics  computers,  devices,  sensors  or  indicators.  Most 
avionics  computers  also  have  a  general  purpose 
communication  bus  (e.g.,  MIL-STD-1553,  High  Speed  Dau 
Bus)  for  data  transfer  among  the  other  avionics  computers  in 
the  weapon  system.  Newer  weapon  systems  usually  have 
many  communication  busses.  Occasionally,  avionics 
computers  also  have  a  dedicated  high  speed  communication 
channel  for  transfer  of  large  amounts  of  data  (usually 
minimally  processed  data)  directly  from  one  point  to  another. 
In  general,  for  complete  testing,  all  the  avionics 
communications  and  interfaces  need  to  be  monitorable  and 
controllable.  Monitoring  is  complicated  by  the  higher  data 
rales  of  the  communication  busses  and  especially  by  the 
dedicated  high  speed  channels.  Monitoring  these  signals 
usually  requires  special  purpose  hardware.  The  ability  to  filter 
unneeded  data  and  trigger  on  events  wiU  reduce  the  quantity 
of  the  data  and  extract  the  precise  information  that  is  required 
for  the  lest  Control  has  some  technical  limitations.  For 
example,  a  dedicated  high  speed  channel  that  connects  two 
avionics  boxes  in  the  test  station  may  have  some  very  strict 
timing  and  handshaking  requirements.  A  specially-designed 
hardware  device  inserted  between  the  two  avionics  boxes  may 
not  be  able  to  receive,  detect,  alter,  and  transmit  the 
communications  and  still  meet  the  timing  requirements.  This 
problem  can  usually  be  overcome  by  simulating  one  of  the 
avionics  boxes  and  driving  the  high  speed  signals  with  an 
interface.  The  simulation  can  then  be  used  to  alter  the  data 
while  driving  the  interface.  The  flexibility  of  the  VTS  will 


enable  changes  in  the  monitoring  equipment  and  avionics 
configurations  in  accordance  with  the  current  test 
requirements. 

6.6.3  Avionics  Computer  Monitor  and  Control 
Both  a  manual  and  an  automated  monitor  and  control 
capability  are  essential  for  testing  and  debugging  avionics 
software  executing  m  an  avionics  cianpulcr.  This  capability 
will  be  used  to  load  software  into  the  avkmKS  computer  and 
observe  the  software  executing  in  real  time.  Monitor  and 
control  functkms  will  include  software  download  and  upload; 
memory  reads,  writes  and  searches;  register  reads  and  writes; 
avionics  hardware  hall,  run  and  reset;  instruction  single  step; 
breakpoint  set  and  clear;  timing  between  events;  event- 
triggered  data  recording;  and  event- triggered  program  trace. 

Several  technical  issues  are  associated  with  halting, 
continuing,  and  single-stepping  avionics  subsystems.  First, 
once  an  avionics  subsystem  is  halted,  it  typically  becomes 
very  complicaled  to  resume  real-time  operation  at  the  point 
where  it  left  off.  Internal  timers,  intenupts.  and  other  time- 
critical  and  status -dependent  hardware  functions  lend  to 
change  state  after  the  halt,  and  it  is  often  impossible  to 
reliably  reinitialize  the  hardware  u>  enable  it  to  continue.  It 
is  usually  best  to  reset  the  hardware  to  resume  operation. 
Secondly,  single-stepping ’s  an  effective  way  to  test  the  basic 
internal  logic  of  the  software,  as  long  as  the  user  understands 
the  limiutions  of  non-real-time  operatkm  and  the  problems 
with  continuing  real-time  execution.  Thirdly,  single  stepping 
the  simulation  software  and  multiple  avionics  computers  is 
especially  difficult.  The  defmition  of  a  single  step  for  a 
system  with  multiple  processors  executing  at  different  clock 
rates  is  a  basic  problem.  In  addition,  all  of  the  processors 
have  to  be  synchronously  stepped.  A  full-featured  real-time 
monitor  and  control  capability  is  usually  a  better  approach 
than  single-stepping.  The  problems  of  halting  and  continuing 
the  processors  are  avoided,  and  the  results  arc  more 
trustworthy  because  they  are  closer  to  actual  operation. 

Traditionally,  real-time  avionics  computer  monitor  and  control 
has  been  very  expensive  because  of  the  complexity  of 
monitoring  a  processor,  the  speed  of  the  events  that  have  to  be 
monitored,  and  the  lack  of  readily  available  interface  signals 
that  support  monitoring.  Also  in  the  past,  a  strong  effort  has 
been  msle  to  insure  that  the  liming  of  the  processor  is  not 
altered  by  the  monitoring  equipment  As  processors  evolve, 
new  hardware  features  such  as  cache  memory,  pipeline 
processing,  superscalar  processing,  high  speed  processing, 
multi-processing,  and  "computers  on  a  chip"  have  made  it 
difTicull  to  monitor  the  processor.  Newer  software  techniques, 
such  as  dynamic  variable  memory  allocation  and  dynamic 
software  task  reconTiguration,  iiKreasc  the  complexity  of 
tracking  the  execution  of  the  software.  Consequently,  future 
avionics  subsystems  will  require  part  of  the  actual  avionics 
software  to  be  dedicated  to  real-time  testing.  Furthermore, 
since  the  avionics  will  be  tested  with  the  embedded  test 
software,  that  software  must  remain  in  the  final  operational 
software  to  avoid  invalidating  previous  tests.  The  avionics 
software  together  with  special  monitoring  hardware  will 
provide  a  full  avionics  computer  monitor  capability. 
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<.7  RmI-TIbi*  Avionic*  Cani|intcr  Eniniatioa 
The  real-tune  hardware  emulator  will  be  capable  of  loading  an 
actual  unmodified  OFP  and  executing  it  at  the  same  rate  as 
that  of  the  actual  avionics  cranpuler.  Real-time  avionics 
computer  emulators  are  usually  implemented  in  hardware  to 
meet  throughput  and  other  timing  requirements.  The  real  time 
emulator  will  be  used  for  several  purposes.  1)  It  will  act  as 
a  high  fidelity  model  to  improve  the  simulation  accuracy  and 
to  reduce  the  maintenance  costs  of  the  simulation.  2)  It  will 
be  used  to  debug  software  for  avionics  computers  that  are 
very  hard  to  monitor.  Since  the  emulator  will  be  a  laboratory 
based  tool  designed  for  testing,  all  the  available  signals  and 
"hooks"  will  be  added  to  su{^x>rt  a  full  avionics  monitor  and 
control  capability.  31  It  will  save  equipment  costs  by  avoiding 
the  need  for  special-purpose  stimulation,  such  as  high 
frequency  RF  signals,  which  might  be  required  by  the  actual 
avionics  computer  it  emulates.  4)  It  will  be  much  less 
expensive  to  produce,  acquire,  and  maintain  than  the  actual 
avionics  computer.  The  real-time  avionics  computer  emulator 
has  many  advantages,  however,  it  will  never  replace  the  actual 
avionics  equipment  in  the  laboratory.  It  is  a  very  useful  tool, 
especially  in  the  early  stages  of  testing  and  when  facility 
funding  is  limited.  Figure  10  illustrates  real-time  avionics 
computer  emulation. 


Figure  10,  Real'TIm*  Avionics  Computer 
Emulation 

7.  INTEGRATIOK  TESTIIVG 

Integration  testing  will  begin  when  subsystem  testing  is 
complete.  During  integration  testing,  the  avionics  subsystem 
will  be  incrementally  integrated  with  the  other  avionics 
subsystems  in  the  weapon  system.  The  OFP  engineer  will 
determine  how  well  the  OFPs  functions  in  concert  widi  the 
other  avionics  computers  and  devices,  and  will  test  higher 
level  functions  that  were  allocated  to  multiple  subsystems. 
Depending  upon  the  level  of  integration  and  the  number  of 
avionics  computers  in  Uie  weapon  system,  integration  testing 
will  consist  of  one  or  more  steps.  Each  step  will  incorporate 
additional  avionics  subsystems  and  will  bring  the  test  system 
closer  to  the  real  weapon  system.  The  VTS  will  be  used  to 
produce  test  station  configurations  with  various  combinations 
of  real  avionics,  emulated  avionics,  and  simulated  avionics,  as 
the  software  progresses  through  integration  testing. 


monitored  and  verified  for  correctness.  The  OFP  engmeer 
will  have  full  mcmior  and  control  capability  ovei  all  the 
subsystem  computers.  With  this  capability,  the  OFP  engineer 
will  initiate  stimulation  of  the  subsystems,  moniux  the 
responses,  and  observe  the  execution  of  the  software.  Thus 
the  OFP  engineer  will  be  able  to  verify  conformance  to 
interface  requirements,  check  the  basic  operation  of  the 
sofbvare.  and  isolate  any  discrepancies  in  the  software. 

Like  subsystem  testing,  the  second  level  of  testing  will  be 
fully  dynamic  and  scenario  oriented.  The  environment 
external  to  the  weapon  system  will  be  simulated,  and  the 
avionics  components  not  present  in  the  given  test  station 
configuration  will  be  simulated  U)  provide  a  fully  interactive, 
real-time  environment.  The  subsystems  will  be  "nown" 
through  various  scenarios  in  a  realistic  controlled  environment 
able  to  exercise  the  subsystem  OFPs  in  a  variety  of  dynamic 
modes.  The  tests  will  be  designed  for  the  specific  subsystems 
under  tesL  The  tests  will  focus  on  verifying  integrated 
functions  performed  by  multiple  subsystems.  The  simulation 
and  real-time  avionics  monitor  and  control  capability  will  be 
used  either  manually  or  automatically  u>  execute  tests 
verifying  correct  operation,  and  to  isolate  any  discrepancies  in 
the  software.  Once  both  integration  lest  types  have  been 
performed,  their  results  will  be  recorded  in  a  software  test 
report.  Revisions  to  documentation  or  code  and  retesting  of 
the  eSUs,  CSCs,  and  CSCIs  will  be  based  on  the  results  of 
the  integration  testing. 

The  integration  testing  will  use  all  the  uxils  used  earlier  in 
subsystem  testing  with  one  additional  renuiremcni.  The 
avionics  computer  monitor  and  control  will  support  multiple 
avionics  computers  by  providmg  a  common  time  tag  and  cross 
triggering  of  events.  For  example,  an  event  in  one  avionics 
computer  (e.g.,  subroutine  call,  branch  taken,  variable  out  of 
range)  will  be  able  to  cause  instruction  tracing  to  begin  on 
another  computer.  The  data  from  both  avionics  computers 
will  then  be  correlated  and  analyzed.  Multiple  avionics 
computer  monitor  and  control  will  give  OFP  engineers  a 
system-level  view  to  support  the  testing  and  debugging  of 
highly  integrated  functions.  Figure  II  illustrates  integration 
tesL 
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Like  subsystem  testing,  basic  interface  testing  will  initially  be 
performed  with  stadcally  generated  data  when  appropriate  for 
the  subsystems  configured  in  the  test  station.  The  subsystems 
will  be  stimulated  with  specific  inputs,  and  the  outputs  will  be 
verified.  The  inputs  to  the  subsystems  will  be  produced  from 
pre-generated  data  and  then  executed  according  to  the  real¬ 
time  requirements  of  the  subsystems.  The  outputs  will  be 


FIgur*  11,  Intugratlon  Test 

S.  AVIOMCS-SYSTEM  TESTING 
Avionics-system  testing  will  begin  once  integratiem  testing  Ls 
complete.  During  avionics-system  testing,  almost  all  of  the 
actual  avionics  will  be  present  in  the  test  station.  The 
electrical  characteristics  (e.g.,  electrical  noise,  cross  coupimg 
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of  Signals,  power  fluctuations)  of  the  avionics  hardware  within 
the  test  station  will  be  nearly  identKal  to  that  of  the  actual 
aircraft  The  OFP  engineer  will  determine  how  well  the 
software  functions  within  the  full  avioiucs  sysusm.  A  System 
Test  Station  (STS)  will  be  used  to  perftxm  the  testing.  Most 
of  the  avionics-system  testing  will  K  performed  manually. 
Automated  testing  will  be  limiteil  by  the  requirement  for  a 
large  number  of  acnial  as  ionics  hardware,  and  the  requirement 
to  maintain  the  actual  electrical  characteristics  of  the  avionics 
system.  Testmg  will  be  conducted  in  both  suttionary  mode 
and  simulated  flight  mode.  Stationary  testing  is  like  testing 
an  aircraft  parked  on  the  runway.  It  allows  the  maximum 
amount  of  avionics  to  be  physically  present  in  the  system. 
Many  tests  not  requiring  flight  will  be  conducted  in  this  way. 
Tests  that  need  aircraft  flight  require  simulation  of  the  external 
environment  and  aerodt  namics.  In  addition,  enough  of  the 
avionics  will  be  simulated  to  make  the  remaining  avionics 
"think  it  is  flying."  Also,  sensors  have  to  be  either 
dynamically  stimulated  or  removed  from  the  configuration  and 
simulated.  Simulated  flight  enables  testing  of  the  dynamic 
functions.  Duimg  avionics-system  testing,  additional  system 
charactcri/ation  measurements  and  u:sts  will  be  run  to 
measure  and  test  functions  that  cannot  be  tested  without  most 
of  the  real  avionics  in  a  system.  For  example,  timing  is 
especially  critical  when  dropping  bombs  on  a  target  The  time 
that  elapses  between  the  stores  management  system's 
command  to  release  a  bomb  and  the  actual  release  of  the 
bomb  must  be  measured  accurately  because  of  the  speed  of 
the  aircraft.  The  software  has  to  compensate  for  the  delay  in 
transmitting  the  bomb  release  command,  having  the  bomb- 
release  hardware  receive  the  command,  and  physically 
releasing  the  bomb.  This  type  of  measurement  can  only  be 
made  with  the  actual  hardware.  The  stationary  and  simulated 
flight  avionics-system  tests  will  be  performed  and  the  results 
of  the  tests  will  be  rc^-irded  in  a  software  test  report. 
Revisions  to  documentation  or  code  and  retesting  of  the 
eSUs,  CSCs.  and  CSCIs  wiU  be  based  on  the  results  of  the 
avionics-system-level  testing. 

Avionics-systcin  testing  will  use  some  of  the  tools  used  in 
integration  testing  including  partial  use  of  the  VTS,  lest  case 
generation,  automated  real-time  testing,  data  monitor  and 
control,  and  real-time  avionics  computer  emulation.  The 
avionics-system  testing  will  be  conducted  using  the  System 
Test  Station  (STS).  Figure  1 2  illustrates  avionics-system  lest. 


bench"  or  a  "hot  mock  up."  It  will  contain  a  nearly  complete 
set  of  avionics,  a  few  avionics  compuuir  mierfaces,  a  few 
avionic'  models,  and  environment  models  The  simulation 
resources  wiU  be  allocated  from  \  I  S  resources.  Monitoring 
will  be  restricted  only  to  those  signals  that  can  be  shown  to  be 
unaffected  by  the  addition  of  monitoring  equipment.  A 
typical  weapon  system  will  require  multiple  STSs  to  support 
different  fielded  avionics  hardware  configurations.  SiiKe  the 
STS  is  very  similar  to  the  actual  weapon  system,  it  can  also 
support  validation  of  the  VTS  hardware  and  software.  Figure 
13  illustrates  a  system  test  station. 
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9.  WEAPON-SYSTEM  TESTINti 
Weapon-system  testing  will  begm  when  all  ground-based 
testing  has  been  completed.  Weapon-system  testing  will 
insure  that  the  new  software  functions  conectly  with  the  entire 
weapon  system,  that  the  system-level  requirements  are  met, 
and  that  any  lower  level  requirements  not  readily  testable  in 
a  ground  based  laborauiry  are  tested.  Throughout  the  lest 
process,  portions  of  tests  may  be  deferred  u>  later  stages  of 
testing  because  of  difficulty  in  producing  the  actual  test. 
Tests  will  use  the  most  technically  appropriate  a,.J  cost 
effective  approach.  Weapon-system  testing  will  involve 
loading  an  actual  test  aircraft  with  the  software  changes  and 
testing  it  first  on  the  ground  and  then  in  actual  flight.  The 
weapon-system  tests  will  be  performed,  and  the  results  of  the 
tests  will  be  recorded  in  a  software  test  report.  Revisions  to 
documentation  or  code  and  retesting  of  the  CSUs,  CSCs,  and 
CSCIs  will  be  based  on  the  results  of  the  weapon -system 
testing.  Figure  14  illustrates  weapon-sysuim  testing. 


FIgur*  12,  AvIonlcs-SystMit  T*st 
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System  Test  Station  (STS)  based  tests  will  be  the  final  stage 
of  testing  prior  to  weapon-system  test.  Therefore,  it  is  critical 
that  the  avionics  operate  very  close  to  the  way  it  will  operate 
on  the  aircraft  The  STS  has  traditionally  been  called  a  "hot 
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9.1  Flight  T*it  Aircraft  aa^  Raagc  AncU 

Flight  test  will  require  a  fully  insmuiietued  aircraft  and 
asaocialed  teat  range  aascts.  (The  author  lacks  experience  and 
knowledge  in  the  specifics  of  flight  lest;  therefore,  specific 
requirements  for  the  flight  lest  aircraft  and  the  test  range  are 
not  provided.) 

9.2  Flight  Test  Data  Analysis 

Due  to  the  cost  of  flight  test  there  is  a  tendency  to  log  a  lot 
of  data.  Consequently,  most  flight  tests  produce  large 
quantities  of  data  that  are  never  used.  Since  the  focus  of 
collecting  the  test  dau  is  the  flight  lest  itself,  flight  lest  data 
is  usually  not  used  for  other  functioiis,  such  as  validating 
simulation  models  and  emulators  or  supporting  stimulation  of 
the  avionics  with  actual  flight  dau.  Three  main  capabilities 
will  be  required  for  flight  test  dau  analysis.  First,  an 
automated  dau  processing  and  dau  visualization  capability 
will  be  used  to  reformat  the  test  dau  and  then  perform 
automated  dau  analysis  or  manual  dau  visualization.  Manual 
dau  visualization  will  use  an  interactive  color  graphics  display 
to  present  the  dau  in  various  alphanumeric  and  graphical 
displays,  which  will  allow  an  OFF  engineer  to  quickly 
understand  and  analyze  large  quantities  of  dau.  Second,  the 
flight  test  dau  will  be  used  to  support  validation  of  the 
simulation  models  and  emulators  by  comparing  simulation 
dau  with  actual  flight  lest  dau.  Third,  the  VTS  will  be  used 
to  "play"  real  flight  test  dau  back  in  the  simulation  in  order 
to  stimulate  the  software  with  real  aircraft  dau  and  to 
reproduce  problems  in  the  laboratory  that  were  identified  in 
flight  test  The  avionics  computer  monitor  and  control 
capability  will  then  be  used  to  monitor  the  processors  and  find 
the  software  problem.  The  Umiutions  of  flight  test  dau 
playback  are  potentially  significanL  Due  to  logging  capacity 
and  instrumenuiion  limiutions,  flight  test  dau  is  usually 
mcomplete.  It  is  often  hard  to  recreate  the  initial  conditions 
of  the  avionics  prior  to  turning  on  flight  lest  dau  collection. 
In  addition,  dau  needed  to  make  the  playback  complete  is 
frequently  not  instrumented  and  logged  during  the  flight  test 
For  example,  the  avionics  dau  busses  are  usually  logged,  but 
many  discrete  and  analog  signals  may  not  be  logged.  When 
recreating  the  flight-test  events  in  a  ground  based  simulation, 
the  dau  bus  information  can  be  played  back  appropriately,  but 
the  discrete  and  analog  signals  have  to  be  synthesized  in  some 
way.  Without  the  full  set  of  signals,  it  may  be  nearly 
impossible  to  recreate  the  full  flight  test  scenario. 
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10.  Conclusioa 

This  paper  was  written  to  document  a  baseline  understanding 
of  a  next  generation  process  and  tool  set  required  to  support 
validation  and  lest  of  complex  weapon  systems.  The  process 
and,  especially,  the  tools  are  constantly  evolving  due  to 
technological  advances  and  continued  research.  The  United 
Suies  Air  Force,  Wright  Laboratory,  Avionics  Logistics 
Branch  (WIVAAAF)  has  conducted  research  in  this  area  for 
many  years  and  has  supported  numerous  research  projects 
centered  on  the  process,  methods,  and  tools  referred  to  in  this 
paper.  Some  of  the  research  areas,  names  of  the  projects,  and 
pomts  of  contact  are  listed  in  the  ubie  below.  WL/AAAF 
recognizes  the  magnitude  of  avionics  test  problems  and 
continues  to  team  with  other  organizations,  extending  research 
to  discover  new  solutions. 
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Discussion 


Question  J.  BART 

Can  you  use  pregeneiaied  tests  to  drive  higher  levels  of  testing? 

Reply 

Yes  you  can.  but  the  time  and  engineering  lequiied  to  generate  the  data  make  it  very  difTicult.  Avionics  typically  cycles 
at  at  least  SO  times  per  second.  Vast  amounts  of  data  are  required  for  even  a  short  test.Tbe  higher  the  level  of  test,  the 
more  data  must  be  pregeneraied.  For  this  reason,  both  dynamically  and  statically  generated  dau  should  be  providied.  but 
sutkally  generated  data  tend  to  be  used  in  the  earlier  stages  of  testing.  Dynami^y  generated  data  tend  to  be  used  at 
later  stages. 
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1.  SUMMARY 

The  ability  to  accurately  test  a  system  which  you  are 
developing  is  a  highly  desirable  feature  in  the  engineering 
design  process.  The  ability  to  model  your  system's 
environment  and  to  exercise  your  system,  in  (hat 
environment,  is  also  highly  desirable. 

Operational  Flight  Programs  are  the  software  programs  of 
avionics  embedded  computer  systems.  Not  only  is  it 
desirable  to  be  able  to  test  and  model  Operational  Right 
Programs,  it  is  esseiUial.  The  consequences  of  not 
performing  accurate  Operational  Flight  Pn  gram  testing  can 
be  devastating.  Some  of  these  include  premature  weapon 
releases,  erroneous  flight  instrument  displays,  and  complete 
system  failure. 

In  order  to  test  Operational  Right  Programs,  there  are 
several  things  one  must  know  about  the  Operational  Right 
Program,  its  weapon  system  host,  its  support  environment, 
and  how  to  generate  and  perform  its  test.  This  paper  will 
address  these  issues  as  it  develops  a  strategy  to  test  an 
Operational  Right  Program. 


Figure  1 

2.  INTRODUCTION 

Embedded  computers  are  increasingly  called  upon  to 
provide  high-tech  solutions  to  complex  multiple  threat 
environments  tor  today's  generation  of  weapon  systems 
(Ref  6).  The  empowering  of  an  embedded  computer  is  its 
software,  which  is  the  Operational  Right  Program. 


In  understanding  the  role  of  an  OFP,  one  must  thoroughly 
understand  the  threat,  the  weapon  system,  the  mission,  the 
embedded  computer  system,  attd  the  complex  testing  issues 
associated  with  OFPs  (Ref  7). 

The  ultimate  success  of  an  updated  Operational  Right 
Program  is  that  the  new  OFP  becomes  an  operational 
version.  Although  several  layers  of  testing  must  be 
successfully  passed  before  OFPs  are  operationally 
acceptable.  Right  tests  are  expensive,  as  are  full-up 
simulations.  But  some  confidence  can  be  gained  through 
evaluating  the  OFP  through  a  simulation  enviroruneni.  The 
simulation  environment  lakes  advantage  of  real-time 
avionics  hardware,  realistic  simulation  software,  and  the 
adaptability  of  advanced  technologies  to  ptrovide  a 
capability  for  testing  the  weapon  system,  the  weapon 
system's  subsystems  and  units,  and  the  weapon  system's 
software  (the  OFPs)  (Refs  7,9). 

Testing  Operational  Right  Programs  requires  an 
understanding  of;  how  OFP  architecture  and  processes 
work;  how  an  OFP  is  changed;  the  major  components  of  an 
OFP  and  its  support  environment;  the  OFFs  interaction 
with  its  users/mainiainers;  OFP  testingA'alidation  issues; 
breadth  and  depth  of  OFP  tests;  and  how  OFP  test  results 
are  analyzed  and  interpreted  (Refs  4,7). 

3.  OFP  ARCHITECTURES  AND  FUNCTIONS 
The  Operational  Flight  Program  literally  is  the  software 
portion  of  a  embedded  computer  system.  The  computer  and 
its  peripheral  interfaces  make  up  the  system  hardware.  'The 
hardware  enabled  by  the  OFP  sof'ware  describes  the  whole 
system. 

The  OFP  is  made  up  of  a  scries  of  modules  which  represent 
the  functions  of  the  weapon  system.  'These  functions 
describe  the  mission  phases  which  the  weapon  system  can 
perform.  Mission  phases  include  preflight,  Uikeoff/time 
to  cruise,  outbound  cruise,  SAM  (surface  to  air  missile) 
evasion,  descent,  penetration,  bomb  delivery,  climb, 
air-to-air  combat,  inbound  cruise,  loiter,  and  approach 
and  landing.  Function  types  include  communication 
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(cxienul/iniernal),  IFF  (idcnUrication  friend  or  foe), 
naviguioii,  guidance,  steering,  contiul,  target 
acquisition/identirication,  stores  management,  weapon 
delivery,  and  threat  wanting.  The  modules  of  the  OFP 
include  executive,  control  and  display,  air-to-air, 
air-to-ground,  navigation,  communication,  heads  up 
display,  vertical  situation  display,  gun,  missiles,  overload 
warning,  and  visual  identificaliun.  A  module  type,  such  as 
controls  and  displays,  might  contain  multiple  modules 
which  are  prioritized  according  to  the  timing  requirements 
of  the  functional  calls  of  the  OFP.  The  OFP  is  required  to 
process  real  time  interrupt  driven  schedules,  which  are 
handled  by  the  executive  modules.  The  modules  of  the 
OFP  are  made  up  of  machine  level  object  code.  Access  to 
this  object  code  by  OFP  maintainers  is  through  a  higher 
order  language  source  code  which  can  be  compiled  to  the 
object  code.  Examples  of  higher  order  languages  used  in 
maintaining  OFPs  are  Ada,  COBOL,  and  FORTRAN  (Refs 
2,6,7,8). 


Figure  2 

The  embedded  computer  system  (see  Figure  2)  has 
partitioned  m.mory  which  is  filled  with  some  type  of 
machine  level  object  (binary)  code.  The  OFP  is  loaded  into 
this  partitioned  memory,  and  when  enabled,  empowers  the 
whole  system  to  perform  its  desired  functions.  Each 
embedded  computer  system  has  an  instruction  set  which  is 
burned  into  its  Read  Only  Memory  (ROM).  The  instruction 
set  allows  the  embedded  computer  maintainer  access  to  the 
OFP  as  well  as  the  capability  to  optimize  the  remaining 
partitioned  memory.  The  level  of  sophistication  of  a 
embedded  computer  system  is  a  function  of  the 
programming  expertise  of  its  OFP  maintainers,  its 
instruction  set,  its  memory,  its  hardware,  and  its 
throughput  (Ref  7). 

4.  HOW  IS  AN  OFP  CHANGED? 

Given  a  working  OFP  in  a  working  system,  why  would 
changes  ever  be  necessary?  One  reason  is  that  the  users 
of  the  system  require  an  altered  mission.  As  an  example,  a 
pilot  would  request  a  clearer  display  under  some  dynamic 
threat  condition.  Another  reason  to  change  OFPs  is  that 
some  flaw  is  discovered  while  the  embedded  computer 
system  is  operational.  Some  combination  of  events  rru;;*''. 


cause  partial  or  total  system  failure,  prompting  a 
review  and  redesign  in  the  effected  areas  of  hardware, 
software,  or  both. 

Given  the  usk  of  changmg  an  OFP  (making  a  new  version 
or  even  a  new  block  cycle),  several  steps  arc  followed  to 
bring  about  the  change.  First,  the  requested  change(s)  is 
diagnosed  so  that  it  is  clearly  understood.  Once  the 
OFP  maintainer  thoroughly  urtderstands  the  change 
request,  an  analysis  is  made  of  the  OFP  areas  which  need  to 
be  altered.  Usually  the  OFP  is  made  up  of  a  series  of 
modules  with  specialized  functions.  A  typical  change  might 
impact  three  modules  of  an  OFP  which  contains  40 
modules.  The  OFP  maintainer  will  next  isolate  these 
modules  by  making  copies  of  them  and  implementing 
design  changes  to  the  copies.  The  OFP  maintainer 
integrates  these  modules  by  linking  them  Uigether  with  the 
other  unaltered  modules  to  form  a  unique  OFP.  The  OFP 
maintainers  final  task  is  to  thoroughly  test  this  modified 
OFP  by  putting  it  through  an  acceptance  test  procedure.  For 
a  sizable  OFP  with  several  changes,  a  number  of  OFP 
maintainers  would  follow  these  procedures  simultaneously, 
and  then  a  lead  OFP  maintainer  would  integrab;  and  :JSl  the 
new  OFP  (Ref  7). 


5.  MAJOR  COMPONENTS  OF  OFP  TESTING  AND 
DEVELOPMENT 

S.l  The  Target  Processor 

In  order  to  perform  various  levels  of  testing  on  OFPs.  the 
OFPs  embedded  computer  (also  called  the  target  processor) 
must  be  available  and  accessible.  The  actual  target 
processor  (see  Figure  2)  is  often  used  by  OFP  maintainers  to 
build  a  mockup  support  environment  by  which  they  can 
access  and  test  their  OFP  changes.  When  these  target 
processors  are  used,  an  environment  has  to  be  available 
which  stimulates  the  processor  input  requirements  and 
receives  the  processor  output.  Some  examples  of  inputs  are 
power,  cooling,  and  peripheral  interfaces  (such  as  pilot 
commands  and  aviimics  suite  inputs).  Examples  of  outputs 
include  pilot  displays,  as  well  as,  command  and  control 
logic  for  other  processors  (Ref  7). 


5,2  The  Support  Environment 

In  order  to  maintain  an  OFP,  the  maintainers  require  a 
dedicated  computer  system  and  a  simulation  environment. 
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The  dedicaled  compuler  system  (see  Figures  4  and  S) 
allows  the  maintainer  to  access  the  OFPs  object  code  as 
well  as  to  copy  and  alter  this  code.  The  simulation 
environmem  allows  maimainers  to  run  the  OFPs  which 
enables  them  to  interactively  debug  and  test. 


The  dedicated  computer  system  provides  sysicm 
conventions  which  arc  ctmTiguration  managcmeiU,  security 
procedures,  and  proper  operation  of  the  dedicated 
computer  system. 


The  hardware  of  a  dedicated  computer  system  usually 
includes  mainframe  computers  (or  powerful 
engineering  worltstatiom),  various  types  of  printers,  disk 
storage  devices,  networking,  and  several  access  terminals. 

Embedded  computers  and  dedicated  computers  are 
frequently  confused  as  being  the  same.  These  are  actually 
quite  different.  The  embedded  computer  is  the  target 
processor  which  is  part  of  the  weapon  system.  The 
dedicated  computer  is  outside  of  the  weapon  system  and  is 
used  to  support  the  software  run  on  the  embedded  computer 
system. 


Figure  4 

Simulation  Environment 

OFPs  must  have  a  means  by  which  to  operate  in  real-time, 
that  is,  loading  them  up  in  their  target  processor  and 
exposing  them  to  the  range  of  conditions  (or  a  reasonable 
subset  of  those  conditions)  encountered  while  operational. 
This  allows  the  maintainer  to  actively  debug  the  OFP.  The 
degree  of  complexity  of  the  OFPs  environment  is  directly 
related  to  the  complexity  of  this  simulation  environment.  In 
the  case  of  a  typical  fire  control  computer,  a  method  to 
represent  the  full-up  avionics  suite  and  the  dynamic 
environment  of  the  fighter  is  required.  An  interface  to  all 
cockpit  controls  and  switches,  as  well  as,  an  interface 
between  the  dedicated  computer  system  and  the  simulation 
environment  is  necessary.  Finally,  competent  maimainers. 
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who  know  how  u>  mike  ihe  system  woik.  ire  essenliil. 

The  simulation  can  range  from  a  fully  operational  weapon 
system  (flight  testing  is  very  expensive)  to  an  all-software 
engineering  workstation.  Usually  the  simulation  is  a 
representative  set  of  the  weapon  system's  LRUs  (Line 
Replaceable  Units)  with  software  emulating  the  cockpit  and 
the  dynamic  envitomnent. 

Interaction  with  the  simulation  environment  is  through  the 
dedicated  computer  system.  Simulation  utilities  hosted  on 
the  dedicated  computer  system  allow  the  loading  of  an  OFF 
into  its  Utfget  processor  and  also  allow  the  OFF  to  be 
exercised  dytuunically  or  statically.  These  utilities  also 
allow  recording,  patching,  debugging,  freezing  ,  and  the 
initialization  of  the  OFF  (Refs  2,6,7 ,8). 

5.4  The  Avionics  Integrated  Support  Facility  (.\1SF) 

The  facility  which  houses  the  dedicated  computer  system(s) 
and  the  simulation  enviranment(s)  is  the  Avionics 
Integrated  Support  Facility  (AISF).  Another  name  for  the 
AISF  is  the  Centralized  Software  Support  Activity  (CSSA). 
'The  AISF  supports  one  or  more  embedded  computer 
systems  and  the  associated  OFFs. 

6.  OFF  TESTING  ISSUES 

6.1  The  Requirement  to  Test 

The  requirement  to  test  is  related  to  the  confidence  desired 
of  the  targeted  system  or  subsystem.  Low  level  testing 
might  be  sufficient  for  minor  operational  adjustments  such 
as  flight-line  data  entry.  But  processes  affecting  life 
support,  terrain  following  radar,  and  navigation,  U)  name  a 
few,  require  highly  integrated  testing.  These  processes 
often  require  specialized  testing  which  depend  on  critical 
resources  such  as  specialized  hardware,  test  equipment,  test 
software  patches,  and  OFF  maintainer  expertise  (Refs 
1,2,4 ,5,6,7 ,8,9). 

6.2  What  Is  An  Acceptable  Level  Of  Testing? 

This  question  is  best  asked  of  the  crew  members  of  the 
OFPs  weapon  system  since  it  is  their  task  to  complete 
missions,  as  well  as,  survive.  The  quality  and  quantity  of 
OFF  testing  affects  their  lives.  At  a  minimum,  crew 
members  must  be  assured  of  the  normal  operating 
conditions  of  their  weapon  system.  Additionally, 
maximum  performance  capabilities  should  be  made 
available,  as  well  as,  a  fail  safe  capability  (Refs  2,8). 

63  Iterative  Nature  Of  OFF  Testing 

Usually  OFPs  are  not  acceptable  in  their  first  cut,  even 
when  they  go  through  Operational  Test  and  Evaluation. 
Five  or  six  cycles  through  the  testing  process  is  not  unusual. 
Much  of  this  is  related  to  the  complex  nature  of  OFPs,  poor 
interpretation  of  OFF  engineering  change  requests,  and 
changing  mission  requirements  midstream  in  OFF 
development  (Ref  6). 


7.  TYPES  OF  OFF  TESTS 

7.1  The  Actaplancc  Test  Procedure 

The  OFF  maintainers  primary  lest  is  the  acceptance  lest 
procedure  (ATP).  'This  lest  is  designed  to  check  out  an  OFF 
to  a  degree  that  it  can  be  released  with  confidence  to  flight 
test  and  then  operational  test  and  evaluation. 

The  ATF  is  a  chronological  check  of  the  OFPs  responses  to 
inputs.  Inputs  include  switch  positioning,  preset 
conditions  such  as  altitude  or  airspeed,  and  hardware 
interrupts  to  name  a  few.  The  OFF  is  loaded  into  its 
embedded  computer,  hosted  on  its  simulation  environment, 
and  required  to  respond  to  these  inputs  in  the  form  of  static 
or  dynamic  displays,  which  can  be  checked  against 
expecu»l  resulu. 

The  ATP  fur  a  typical  lire  control  computer  could  contain 
2(X)  or  more  independent  tests  of  varying  degrees  of 
complexity.  The  reliance  of  an  OFF  acceptance  test 
procedure  to  be  visually  verified  and  to  be  manually 
performed  requires  several  weeks  to  complete  (Ref  7). 

T3  The  Baseline  Acceptance  Test  Procedure 

The  baseline  acceptance  test  procedure  (ATP)  is  the  ATP 
which  complemented  the  most  recent  version  of  Ihe  OFF 
(the  last  block  cycle  change).  An  ATP  should  be  developed 
concurrently  with  its  OFF.  That  is  to  say.  any 
additions,  deletions,  or  modifications  to  the  OFF  should  be 
paralleled  by  the  ATP  (Ref  7). 

73  Unit  Tests 

A  unit  test  is  the  lowest  level  of  testing.  With  respect  to  an 
OFF.  a  unit  test  is  at  the  module  level.  As  an  example, 
there  might  exist  some  type  of  looping  mechanism  within  a 
module.  The  check  of  this  loop  might  be  with  a  clock  to 
time  the  loop  or  a  count  down  mechanism  to  track  the 
number  of  loop  iterations  (Refs  7,9). 

7.4  Subsystem  Tests 

A  subsystem  test  combines  units  to  represent  a  functional 
set  of  an  OFF.  In  typical  fire-control  computers,  these 
subsystems  might  include  the  set  of  air-to-air  modules  or 
the  set  of  control  and  display  modules.  Checks  for  these 
types  of  subsystems  include  setting  a  value  in  one  module, 
rurming  the  OFF,  and  inspecting  values  in  other  modules 
against  expected  values  (Refs  2,7,9). 

7.5  Integrated  Tests 

Integrated  testing,  as  seen  in  Figure  6,  can  represent  several 
layers  of  OFF  testing.  Integrated  testing  includes  the 
exercising  of  an  OFF’S  complete  module  set.  It  is  here  that 
the  subsystems  are  checked  out  against  each  other  and 
against  the  OFFs  target  processor  environment.  The 
integrated  test  can  become  increasingly  complex  as  the 
environment  is  more  dynamically  modeled.  An  example  of 
an  increasingly  dynamic  environment  is  changing  from 
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modeled  radar  inputs  to  actual  radar  inputs  being  driven  by 
a  separate  radar  OFF  (Refs  2.3.6,7,8). 

7.6  Static  Tests 

Static  tests  are  tests  which  are  not  time  dependent.  Given 
an  input,  or  a  combination  of  inputs,  there  should  be  an 
expected  response.  As  an  example,  in  gun  mode,  a  gun 
reticle  should  appear  on  the  pilot  displays.  The  gun  reticle 
is  a  circle  displayed  to  a  pilot  on  a  Heads  Up  Display 
(HUD)  and  a  Visual  Situation  Display  (VSD).  The  static 
test  is  that  when  the  gun  mode  is  initiated,  the  gun  reticle  is 
or  is  not  present.  If  it  is  not  present,  it  has  failed  the  test. 

7.7  Dynamic  Tests 

Dynamic  tests  are  much  more  complicated  than  static  tests, 
since  they  are  time  dependent.  They  might  require  a 
sequence  of  inputs  over  some  lime  interval  in  order  to 
ensure  proper  functioning  of  the  OFF.  An  example  of  a 
dynamic  test  is  to  observe  an  expected  Signal-lo-Noise 
Ratio  (SNR)  improvement,  as  range  decreases  on  a  target 
being  tracked  with  radar.  The  difFiculty  of  this  lest  is  that  it 
requires  an  OFF  maintainer  who  can  visually  voify  the  test 
case.  The  maintainer  has  to  know  from  experience  what  a 
sequence  of  responses  should  indicate.  The  quality  of  OFF 
testing  in  the  dynamic  cases  is  often  limited  to  the 
experience  level  of  OFF  maintainers  available  for  testing 
(Refs  2,7). 

7.8  Classillcd  Tests 

Arrangements  must  be  made  few  classified  testing  of  OFI^. 
This  requires  the  facilities  and  maintainers  to  be  cleared  to 
the  level  of  the  classification  of  testing.  It  also  requires  a 


means  of  properly  storing  and  maintaining  classified  testing 
documentation.  It  is  often  convenient  to  isolate  classified 
portions  of  OFF  testing,  so  that  nun-classified  OFF  testing 
can  be  accomplished  with  minimal  restrictions  (Ref  7). 

7.9  Automated  Tests 

As  the  complexity  of  OFFs  increases,  the  ability  to 
manually  perform  acceptance  test  procedures  (ATFs) 
decreases.  Also,  the  ability  to  fully  and  accurately  test 
OFFs  decreases.  One  successful  method  to  increase  the 
OFF  maintainers  ability  to  test  OFFs  is  to  utilize  automated 
techniques.  For  example,  if  in  the  process  of  manually 


running  an  ATP  lest  case,  a  sequence  of  switch  and  dial 
position  can  be  captured  throughspecial  test  software,  then 
that  portion  of  the  ATP  test  case  can  be  automated.  Using 
techniques  like  this  should  reduce  errors  and  the  time  to  run 
through  ATF  and  free  OFF  maintainers  to  develop  more 
comprehensive  test  cases  (Refs  23,4,5,6,7,8,9). 
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7.10  Op«rallDiMl  TmI  Awi  Evalmtioa 

Opciaiiaiul  lest  and  evaluation  is  where  the  OFP  must  meet 
the  approval  of  those  who  will  use  it.  These  users  have 
their  own  check-out  procedures  which  can  include  live 
firing  of  munitions,  lock-on  and  destruction  of  drones, 
TMvigaiional  exercises,  to  mention  a  few.  Operational  test 
and  evaluation  is  the  final  test  of  a  complete  weapon  system 
being  fully  integrated  together.  Several  diffocnt  OFPs  can 
be  evaluated  during  operational  test  and  evaluation. 
Operational  test  and  evaluation  often  Finds  system  and 
subsystem  enors,  which  were  undetectable  in  the  OFP 
maintainer's  simulation  environment.  Often,  OFP  version 
updates  are  termed  by  OFP  maintainers  through  the 
information  they  receive  from  Operational  test  and 
evaluation  (Refs  7,9). 

7.11  Developmental  Test  And  Fvuluation 

Sometimes  during  the  block  cycle  or  version  update  of 
OFPs,  a  more  dynamic  environment  than  the  Avionics 
Integrated  Support  environment  is  required.  Some  test 
situations  can  only  be  examined  through  the  actual 
exercising  of  the  complete  system  in  its  real  environment. 
Developmental  test  and  evaluation  provides  OFP 
maintainers  with  this  option,  usually  through  the  provision 
of  instrumented  flight  test  aircraft.  These  instrumented 
aircraft  can  accommodate  specific  tests  in  an  actual 
operational  environmenL  An  example  of  this  is  the 
recording  of  narrow  band  and  wide  band  data  in  an  air-to-air 
engagement  scenario  which  can  be  analyzed  for  specific 
OFP  performance  parameters  (Refs  7,9). 

«.  HOW  IS  AN  OFP  TESTED? 

8.1  What  is  Normal? 

Before  originating  or  extending  the  OFPs  acceptance  test 
procedure,  a  baseline  must  be  established  which  outlines 
the  system's  normal  performance  parameters  and  the 
environmental  conditions  which  the  system  wil) 
experience.  This  baseline  will  influence  the  testing  design 
decisions  throughout  the  weapon  system's  lifecycle.  In  this 
baseline,  design  considerations  must  include  the  weapon 
system's  embedded  computer  systems,  their  OFPs,  and 
their  interaction. 

Performance  parameters  include  all  of  the  avionics  of  the 
system  such  as  altitude,  air  speed,  angle  of  attack, 
directional  indication,  and  engine  thrust.  Performance  is 
also  the  ability  of  the  air  crew  to  interact  with  the  system 
through  controls  and  displays.  Performance  also  includes 
the  system's  interaction  with  its  environmental  conditions 
through  the  use  of  its  communications,  navigation,  radar, 
electronic  warfare  suite,  and  weapons.  Consideration 
should  be  given  to  the  performance  of  the  system's  OFPs. 
Are  the  OFPs  operating  optimally?  Are  there  unused 
resources  that  can  be  better  shared?  Are  there  potential 
bottlenecks  or  failures  that  can  be  avoided? 


Environmental  conditions  arc  those  situations  that  the 
weapon  system  will  be  exposed  to.  In  the  normal  course  of 
a  mission,  what  dues  the  weapon  system  experience?  The 
weapon  system  is  prepared  for  its  mission  at  its  home  base. 
It  leaves  its  home  base  enroute  to  its  mission,  it  is  refueled 
enruute,  it  maneuvers  to  avoid  tiireats  enroute,  it  performs 
its  mission,  and  it  reverses  its  enroute  to  return  to  home 
base.  Several  environmental  conditions  have  been 
identified  in  this  mission  scenario.  First,  a  maintenance  or 
mission  preparation  environment  is  idcmified.  Second,  a 
navigational  environment  is  pointed  out.  Third,  a  friendly 
air-to-air  refueling  environment  is  called  for.  Fourth,  a 
threat  environment  is  shown.  Fifth,  the  mission 
performance  environment  occurs.  And  finally,  there  is  the 
return  environment. 

In  each  of  the  above  environments  (plus  several  others), 
every  possibility  of  weapon  system  configuration  must  be 
identified.  The  OFFs  influence  on  every  weapon  system 
configuration,  and  subsystem  configuration,  in  every 
environment  in  response  to  the  weapon  system's 
performance  parameters  gives  the  foundational  basis  for  the 
OFP  acceptance  test  procedure.  The  baseline  OFP 
acceptance  test  takes  into  account  every  parameter,  every 
environmental  situation,  and  any  combination  of  parameters 
and  environmental  situations  to  generate  test  cases  which 
exercise  these  various  situations  (Refs  1,2,3,6,7,8.9). 

8.2  What  could  Impact  Normality? 

Given  a  comprehensive  understanding  of  the  system's 
performance  and  the  various  environments  in  which  it 
can  be  exercised,  what  changes,  threats,  or  failures 
should  be  anticipated? 

One  of  the  greatest  benefits  of  using  embedded  computers 
and  software  in  weapon  systems  is  that  these  systems  can  be 
reconfigured  and  adapted  to  changing  mission  requirements 
and  evolving  threats  more  readily  than  older  hardware 
intensive  systems.  There  is  a  cost  associated  with  this 
benefit.  In  a  highly  integrated  weapon  system,  small 
changes  can  effect  large  testing  areas.  It  is  important  to 
know,  before  changes  are  made,  how  ihese  changes 
influence  the  entire  system,  and  what  changes  in  testing 
need  to  be  made  to  facilitate  them. 

The  threat  environment  is  constantly  changing.  It  is 
necessary  fw  weapon  systems  to  be  carefully  mned  to 
certain  threats  in  order  to  defeat  or  avoid  them.  What 
happens  when  a  unique  unanticipated  threat  is  put  up 
against  the  weapon  system?  If  possible,  unique  threats 
should  be  anticipated  and  plarmed  for  in  testing  scenarios. 
Evolving  and  break-through  technologies  often  translate 
into  new  threats.  By  keeping  pace  with  these  new 
technologies,  potential  threats  can  be  included  in  the  test 
plans. 
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System  and  subsystem  failure  should  also  be  considered 
when  anticipating  potential  impacts  on  normal  utsiing.  At 
what  degraded  capability  could  the  system  t^xrate  if 
various  subsystems  were  disabled  (Refs  1,2, 3, 6,7 ,8,9). 

U  Gaocrathm  of  the  An  Acceplance  Test  Procedure? 
Having  established  normal  and  abnormal 

performance  criteria  of  the  system,  a  comprehensive 
acceptatKe  test  procedure  can  be  established.  This  test 
would  begin  by  identifying  and  describing  every  possible 
configuration  of  the  weapon  system  against  every  possible 
environment  that  the  system  would  encounter.  This  test 
would  then  identify,  describe,  and  anticipate  every  abnormal 
situation  which  could  impact  the  system  and  its  subsystems. 
With  the  inventory  of  configuratiems  derived,  a  set  of  test 
cases  would  then  be  generated  to  exercise  these 
configurations.  The  actual  utilization  of  these  lest  cases 
would  determine  the  requirements  for  each  test  case  such  as 
the  static  or  dynamic  testing,  degree  of  integration  with 
other  OFP  compemenis,  simulation  resources,  and  the 
number  of  iterations  of  the  lest  case.  The  compilation  of 
all  this  information  is  the  acceptance  lest  procedure.lt 
should  be  noted  that  using  present  techniques  to  complete 
an  acceptance  lest  procedure,  as  described  for  a  modem 


sufficienliy  satisfy  every  lest  case  in  your  acceptance  lest 
procedure. 

Because  the  maintenance  of  OFPs  has  not  been  prioritized 
in  the  procurement  process,  what  is  used  for  an  acceplance 
test  procedure  is  greatly  stripped  down  from  what  has  been 
suggested.  Current  OFP  acceptaiKC  test  procedures  are 
heavily  dependent  on  the  OFP  mainlainer's  subjective 
experience.  The  passing  or  failing  of  an  OFP  acceptance 
test  procedure  is  based  on  how  these  OFP  maintainers  feel 
about  their  weapon  system.  Though  not  scientific  or 
repeatable,  this  has  been  sufficient  to  field  reliable  systems. 

Future  OFP  acceplance  test  procedures  will  demand 
identifiable  and  repeatable  processes  in  order  to  guarantee 
weapon  system  reliability  The  immiase  in  configurational 
situations  alone  will  disqualify  the  subjective  expert  method 
of  passing  OFP  acceptance  test  procedures.  Future  OFP 
acceptance  test  procedures  will  require  a  comprehensive 
identification,  description,  and  anticipation  of  the 
situations  the  system  will  and  might  experience.  In 
addition,  future  OFP  acceptance  test  procedures  will  need 
methods  to  lest  these  situations. 


OFP  Testing  Issues 


weapon  system,  would  take  several  man  months,  with  many 
of  the  configurations  untestable  (Refs  1,2,3,6,7,8,9). 

8.4  Passing  The  Test? 

What  qualifies  an  OFP  as  passing  its  acceptance  lest 
procedure?  The  obvious  answer  is,  you  pass  when  you 


8.5  Increasing  Levels  of  Integration 

The  nature  of  weapons  platforms  is  to  increase  in 
complexity.  The  ability  to  increase  in  complexity  has  been 
largely  facilitated  by  using  embedded  computer  systems  and 
software.  These  embedded  systems  are  increasingly  linked 
together  (or  integrated)  to  take  advantage  of  shared 
resources.  The  consequences  of  increased  integration  is 
increased  complexity  in  the  ability  to  test  the  weapon 


22-« 

system.  When  subsystems  are  isolated,  changes  in  those 
subsystems  have  little  or  no  impact  on  the  overall  weapon 
system.  When  these  subsystems  are  integrated  through 
some  shared  resources,  changes  in  a  subsystem  potentially 
impacts  all  of  its  sharing  partners. 

Unfortunately,  as  systems  have  become  more  complex,  the 
capability  to  test  these  systems  has  not  kept  pace.  This  is 
largely  due  to  the  fact  that  the  procurement  process  has  not 
provided  for  or  anticipated  the  maintenance  requirements  of 
advanced  avionics  software,  it  is  well  documented  that 
70%  or  more  of  a  system's  life  cycle  cost  will  be  in  the 
maintenance  of  that  systems  software.  A  large  portion  of 
this  cost  lies  in  the  system's  testing  (Refs  7,9). 

For  every  increased  level  of  system  integration,  at  least 
equal  thought,  design,  and  resources  should  be  dedicated 
to  testing.  This  will  require  new  analysis, 
methodologies,  and  testing  techniques  (Refs  2,3,4,5,6,7,8). 

8,6  Need  for  Advanced  Technologies 

in  order  to  assure  the  successful  operation  of  current  and 
future  avionics  weapon  systems,  as  well  as,  the  growing 
number  of  system  platforms  implementing  highly  integrated 
embedded  computer  systems  and  software,  advanced 
avionics  testing  techitologies  must  be  encouraged  and 
accelerated,  ^me  of  the  areas  to  be  pursued  include: 
improved  instrumentation  techniques;  development  of 
integrated  diagnostics  techniques  (especially  in  the  area 
ofsoftware  integrated  diagnostics);  continued  emphasis  on 


automated  testing  techniques,  development  of  advanced 
verifkation  and  validation  techniques;  expansion  of 
avionics  software  reuse  libraries;  improved  simulation  and 
testing  environments;  increased  implementation  of 
hypermedia  and  virtual  reality  technologies  into  the  OFF 
testing  environments;  and  continued  development  of  human 
factor  engineering  (Refs  23,4.6,7,8). 

The  encouragement  and  implementation  of  these  types  of 
technologies  will;  enable  the  weapon  system  u>  monitor 
itself  while  it  is  operational;  return  from  its  mission  and 
give  its  maintenance  staff  a  comprehensive  performance  and 
diagnostics  report;  suggest  new  techniques  for  evaluating 
complicated  highly  integrated  OFPs;  and  identify  reserve 
capabilities  and  opportunities  for  the  weapon  system 
(Refs  2.8). 

9.  CONCLtSIONS 

Operational  Flight  Programs  hosted  on  embedded  coini'  .  i-r 
systems  have  greatly  extended  the  capabilities  of  avioi.  ^ 
weapon  systems.  These  extensions  have  increascii  ic<. 
weapon  systems  lethality;  the  air  crews  survivability .  and 
the  capability  of  the  system  to  be  reconfigured  as  well  as 
decreased  the  weapon  system  turn  around  time  In  order  to 
be  further  extended,  a  new  emphasis  must  be  placed  on  the 
testing  of  Operational  Flight  Programs.  This  new  emphasis 
IS  dependent  on  the  inclusion  of  advanced  avionics 
technologies  into  existing  and  planned  Avionics  Integrated 
Support  Facilities.  It  is  also  dependent  on  all  individuals 
involved  in  the  acquisition  and  maintenance  of  weapon 
systems  containing  OFPs  to  be  aware  of  what  it  takes  to 
have  confidence  in  the  software. 
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Technology  Insertion  to  Improve  OFP  Testing 


Figure  8 
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Discussion 

Question  C.  ANTOINE 

How  will  the  use  of  Ada  and  OOD  impact  the  OFP  testing,  in  pankular  the  flight  testing  activities? 

Reply 

Ihe  and  near  future  of  Ada  and  OOD  will  have  little  impact  on  CtfT*  testing  because  of  the  enormous  amoum 

of  non  standard  code  in  use  in  the  inventory. 

What  these  can  impact  now  is  improve  software  engineering  practices  amongst  those  developping  and  maintaining 
software.  When  disciplined  softuw  becomes  standard  in  development,  huge  opportunities  will  exist,  because  not  only 
re-usable  software  will  be  availaMe  accross  weapon  systems.  Tbis  will  include  support  environnrent.  software  and  test 
cases. 

OOD  most  certainly  will  enable  re-use  libraries,  which  will  also  avail  new  opportunities.  Note  that  flight  testing  is 
hugely  expensive  and  weapon  system  dependent  These  alone  hinder  absorbtion  of  new  techniques. 

By  the  way,  F-22  will  have  many  challenges  in  OFP  testing  even  with  its  Ada  advantages. 

Question  K.  BRAMMER 

You  mentionned  re-use  as  one  of  the  technologies  with  potential  benefit  Re-use  can  be  practiced  at  all  levels  of  the 
system  hieracby,  firom  CSU  level,  CSC  level  and  so  on  up  to  subsystem  level.  I  am  interested  in  your  opinion,  at  which 
these  levels  re-use  would  be  most  desirable,  i.e.  rather  at  the  upper  levels  or  at  the  lower  ones  and,  may  be,  depending 
on  the  applicaiion  domain? 

Reply 

I  am  most  interested  in  RE-USABLE  COMPCH4ENTS  at  the  lowest  levels.  I  would  like  to  see  hardened  proven  "units" 
which  can  be  "grabbed"  and  "used"  accross  dissimilar  systems.  Much  work  has  to  be  done  to  design  this  type  of  software 
unit  to  be  robust  Namely,  techniques  to  quantify  and  qualify  conqxments. 

For  larger  units  (subsystems),  todays  limitations  are  protaibitive.  It  may  be  possible  to  have  a  common  subsystem  (such 
as  a  common  radar)  accross  systems. 

To  make  software  components  accountable  to  quality  standards,  we  have  to  develop  new  techniques  to  measure  and 
diagnose  software  dynamically.  Tbis  capability  does  not  exist  I  propose  rigorous  new  research  in  software  integrated 
diagnostics  which  will  begin  to  enable  QA  concerns  with  information  to  assure  software  products.  One  component 
necessary  for  software  integrated  diagnostics  is  the  RBOOO's  Buih-In-Suppott  function,  which  is  an  intrusive  (has  a  cost) 
bardware/software  way  of  observing  and  exerdsing  your  system. 

Question  J.  BART 

Are  things  gettii^  better,  eg  wiib  F-16? 

Reply 

The  F-16  SPO  tradidoiially  was  bdd  to  a  sii^le  option.  They  jumped  at  the  opportunity  to  have  a  choice.  Out  Advanced 
Multipurpose  Support  Environment  (AMPSE)  has  been  instrumental  in  allowing  the  F-16  A:B  models  to  be  updated 
timely.  The  new  generation  of  sim  is  also  being  adopted  (COMET),  as  well  as  being  a  BGTA  test  site  for  many 
tedmologies  indudiDg  Autoval  (anlomaied  validation),  FMAC  (programmable  monitor  and  control),  to  name  a  view. 

Unfortunately,  the  CHT*  work  load  systems  like  F-16  and  F-15  AISFs  are  inceasing  beyond  wbat  cuirent  techniques 
cat  handle.  Many  opportimities  exist  for  technology  transitiaa.  The  greatest  need  is  to  leverage  technology  before  crisis 
situations  dictate  continued  band  aide  usage. 

We  need  to  pry  loose  maintenance  people  to  steer  and  transition  ledmology. 
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SUMMARY 

Boibedded  aoftwate  providiiif  the  ftactiouality  for  a  flight 
vehicle  aelf  dealruet  lyatem  waa  judged  to  be  lafoty  critical 
and  required  the  higheat  level  of  aaaurance  in  ita  correcineaa. 
In  order  to  achieve  thia  a  programme  of  independent 
verification  and  validation  waa  initiated  which  involved  the 
definhion  of  a  formal  tpecificatian  of  the  loftware  combined 
with  itatic  aimlyaia  and  dynamic  teiting.  The  formal 
apecification,  written  in  an  Object  Oriented  form  of  Z,  waa 
uaed  to  clariiy  the  requirementa  and  to  provide  a  definition 
againat  which  the  code  could  be  formally  verified.  A  range 
of  atatic  analyaea  were  performed,  culminating  in  Conqtliaiioe 
analyaia  which  effectively  provided  a  proof  of  the  code  againat 
low  level  mathematical  apecificationa  that  were  refined  down 
from  the  Z  apecificaciao.  The  dynamic  teat  aeta  were  choaen 
partly  fiom  the  requirementa  apecification  and  partly  from  the 
atatic  analyaia  teauka  ao  that  complete  path  coverage  through 
every  oKK^  waa  achir/ed.  The  work  revealed  a  number  of 
errora  within  the  code  and  ita  apecificationa,  which  were 
corrected.  Through  ita  rigour  and  the  identificain  n  of  errora 
toe  analyaia  haa  given  a  very  high  degree  of  confidence  in  the 
correctneaa  of  the  aoftwate. 


1.  INTR(H>UCnON 

Safety  Critical  aoftwate  ia  r^atded  aa  that  for  which  a 
aoftware  feihire  could  lead  to  loaa  of  htanan  life.  The 
integrity  of  auch  aoftware  ia  therefore  a  aubject  of  great 
ooncetn  for  developera,  uaen  and  the  general  public.  To 
reflect  theae  concetiu  tbmc  ia  currently  a  proliferation  of 
atandarda  acroaa  a  wide  range  of  induatriea.  At  a  European 
level  two  draft  atandarda  have  recently  been  produced  under 
lEC  fiSA  working  Otoupa  9'  and  10*  and  there  are  a  number 
of  aeolar-qwcifie  indualty  variantt  of  theae  in  production. 
Other  induatry  aecton  have  developed  thm  own  atandarda 
aeparately,  for  example  WC  SSO*  in  the  Nuclear  Sector,  DO- 
I'^A'/B  in  Civil  Aviation  rector  and  Interim  Defence 
Slandarda  00-S^  and  00-SS*  m  the  UK  defence  arena. 

AH  theae  atandarda  have  the  aame  aim,  namely  to  enaure  the 
correctneaa  and  aafcty  of  aoftware  devekqted  under  them.  In 
general  the  ^proach  defined  within  many  of  the  atandarda  ia 
the  aame,  eompriaing  the  initial  conduct  of  ayatem  hazard 
analyaea  leading  to  the  cat^riaation  of  the  aoftware  iido 
erUealky  levek.  Teehniquea,  metboda  and  requirementa  are 


then  defined  for  both  the  deaign  and  verification  of  the 
aoftwate  within  each  criticality  level. 

One  notable  area  of  difference  ia  in  the  avionica  aector,  in 
[Muticular  between  Civil  avionica  aitd  UK  militaty  avionica. 
In  the  former  area  the  emphaaia,  in  practice  if  not  in 
mandatfirl  requirementa,  haa  been  on  the  uae  of  trrhniqiiea 
auch  aa  aoftware  divenity  aa  a  mcana  of  trying  to  eliminate 
the  effect!  of  aingle  aoftware  fiuika.  However,  even  uaing 
diffeteid  teama  in  different  companiea  and  diflimnt 
languagea/hardwarepUtforma,  there  ia  no  guarantee  that  the 
aame  miatake  could  not  exiat  in  more  than  one 
irtqtlemmtarinn.  Puithermore,  there  ia  often  a  common 
requitemenU  apecification  which  ia  a  potential  aource  of 
common  mode  fitihire. 

Fethapa  in  recognitioo  of  theae  problem! ,  and  pethapa  in 
recognition  of  the  extra  coat  that  divenity  bringa,  the 
emphaaia  on  the  UK  military  aide  haa  been  on  'doing  it  once 
and  doing  it  rigid’.  Particular  emphaaia  haa  been  placed  on 
mathematica  and  analyaia,  and  a  very  proacriplive  atandard. 
Interim  Def  Stan  00-55  baa  been  produced  which  mandatea 
the  uae  of  Formal  Method  teehniquea. 

Formal  Methoda  technique!  have  been  ahown  on  particular 
project!  and  in  particular  application  areaa  to  have  aignificam 
benefit!  in  terma  of  aafety  and  correcineaa  of  aoftware.  There 
«,  btnvetrar,  aome  debate  about  their  univeriai 
appropriatenttaa,  in  particular  for  non  trivial  ayatema.  For 
theae  and  other  reaaona  formal  metboda  are  underatood  to  be 
covered  in  ieaa  than  one  page  in  DO-178B,  which  ia  a 
aignifieant  contnat  to  Def  Stan  00-55  which  ia  largely  baaed 
around  the  oonoepta  of  formality  and  proof. 

Wluiat  not  able  to  contribute  to  the  debate  on  auitability  of 
formal  methoda  for  large  ayatema,  thia  p^wr  deacribea  a 
project  where  wefa  methoda,  combined  with  atatic  analyaia 
and  dynamic  leatmg,  were  uaed  aucceaafiilly  on  a  amall 
embedded  aoftware  ayatem. 


Presented  at  tm  AGARD  Meeting  on  Aerospace  St^hvare  Engineering  for  ^<'''anced  Systems  Architectures’,  May  1993. 
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2.  OESCRimWI  OF  APPLICATION 

The  peiticuler  eppucatioa  wu  e  fligol  vehicle  fclf-deetnict 
lydem.  Thia  syitem  wu  to  be  6tted  to  the  vehiclu 
during  range  teeting  and  wu  to  permit  the  destruction  of  the 
vehicle  if  any  problems  arose  during  trial  flights.  The  system 
wu  therefore  judged  to  be  the  highest  level  of  ufiety 
criboality,  since  any  fiulure  to  destruct  when  required  could 
permit  the  vehicle  to  fly  outside  the  range  and  potentially 
cauK  harm  or  damage  to  people  and  property. 

The  self  destruct  system  itself  wu  relatively  simple  in 
opeiation.  Its  overall  function  wu  to  receive  a  radio  signal 
from  the  i^ound  control  system  and,  if  appropriate,  to  set  off 
a  small  explosive  charge  which  would  lead  to  in-flight 
destruction  of  the  flight  vehicle  into  relatively  harmlus 
pieces.  The  main  Ainctionality  of  the  system  wu  provided  by 
software,  written  in  an  S-bit  assembler  (Motorola  6805)  and 
comprising  approximately  500  linu  in  total. 

The  software  wu  required  to  perform  a  number  of  individual 
functions.  Firstly  it  had  to  receive  and  decode  the 
communication  signal.  Sr,  .ndly  it  had  to  interpret  the  signal 
and  decide  whether  it  wu  of  reliance  for  the  particular  flight 
vehicle  (the  system  allowa  for  a  number  of  identical  vehiclu 
being  used  on  a  number  of  different  rangu  at  the  same  time). 
Finally  it  had  to  decide,  based  on  the  signal  received  and  on 
timing  information,  whether  it  wu  necessary  to  initiate 
destruction. 

The  foil  ufe  action  of  the  system  wu  to  uuse  destruction  and 
hence  there  were  a  number  of  duign  featuru  which  aimed  to 
euure,  for  almost  all  powible  foiluru,  that  destruction  will 
take  place.  For  example,  the  ground  system  itself  should 
always  be  issuing  ekber  a  fire  (destruct)  or  prohibit  signal. 
As  well  u  destructioo  being  inkfoted  by  the  appropriate  fire 
signal,  a  timer  within  the  software  should  also  initiate 
destructioo  if  a  prohibit  signal  bu  not  been  received  for  a 
pie-defined  length  of  time  (for  example  if  communication 
firom  the  ground  is  lost).  Finally  there  wu  also  a  hardware 
elunent  to  pick  up  the  case  of  a  software  'lock  up'  where  a 
monostable  would  cause  initiation  if  it  bad  not  received  a 
periodic  reset  signal  from  the  software.  Despite  all  these 
preuutions  the  software  wu  still  comkfered  ufety  critical 
since  a  catastrophic  logic  error  could  be  possible  which,  for 
example  kept  the  timers  initiated  but  fiuled  to  act  on  a  fire 
command. 

The  software  wu  developed  'conventionally'  firom  a  lop  level, 
natural  language,  system  requirements  specification  down 
through  a  software  requiietnenls  specification  and  software 
duign  specification,  below  which  wu  the  source  cr  de  itself. 
The  low  level  detailed  specificatioM  for  each  section  of  code 
were  provided  u  code  headers.  No  particulu  structured 
methods  or  tools  were  used  during  the  software  devefopmciU 
proceu. 


3.  OBJECTIVES 

It  is  often  the  case  that  awareneu  of  the  iuuu  relating  to 
software  criticality  occurs  relatively  late  in  a  project.  For 
example,  it  may  not  be  appreciated  at  the  start  of  the  project 
that  the  software  is  ufety  critical  and  therefore  setivkin  will 
not  be  planned  which  will  hc.p  the  certification  of  the 
software.  This  is  likely  to  ruuh  in  additional  costs  at  the  mtd 
of  the  project  which  could  have  been  uved  if  the  iuuu  had 
been  sddresaed  at  the  start. 

To  some  extent  thia  wu  the  case  with  the  software  for  the 
flight  vehicle  self-destruct  system  in  that  TA  Couukancy 
Servicu  were  first  approached  following  the  completion  of 
the  initial  version  of  the  software.  TA  Couukancy  Servicu 
were  requested  to  ensure  that  the  software  wu  acceptable  in 
a  ufiety  critical  application.  Analysu  had  already  been 
carried  out  by  the  syatem/softwaie  manulsctuier  which 
confirmed  that  the  software  wu  ufety  critical.  It  wu 
therefore  necessary  for  the  software  to  be  approved  or 
certificated  u  being  ufe  to  use  before  the  first  flight  of  the 
system 

TA  Consultancy  Servicu  were  requested  to  conduct  aulysu 
and  Indqiendeik  Verification  and  Validation  (IVfeV)  to 
increase  confidence  in  the  correctneu  of  the  software. 
Althaugh  no  standards  had  been  specifically  mandated  for  the 
software  to  meet,  k  wu  also  the  aim  for  TA  Couukancy 
Servicu  to  carry  out  any  retrospective  work  necessary  to 
enable  the  software  to  meet  the  spirit,  if  not  the  letter,  of  Dcf 
Stan  00-55,  which  wu  at  draft  stage  at  the  time. 


4.  OVERVIEW  OF  APPROACH 

At  a  very  simplistic  level  there  are  two  usential  stagu  to 
euuring  the  correctneu  of  a  piece  of  software.  The  first  is 
to  euure  that  the  requirements  specification  is  correct  and  the 
second  is  to  euure  Out  the  code  completely  meets  the 
requirements  specification.  Unfortunately  neither  of  tbew 
activitiu  is  euy.  For  exrunple  the  task  to  ensure  that  the 
requirements  are  correct  is  a  largely  unbounded  problem 
neceuiuting  effective  communkution  wkh  the  potentul  users. 
For  a  non-trivial  system  it  is  very  difficult  to  enviuge  all  the 
specific  requirements  without  exteuive  modelling  and 
simulatioo  of  the  system  and  the  unambiguou  and  complete 
representation  of  the  requirements  is  another  problem  in 
ks^. 

Similarly  Oie  task  of  euuring  that  the  code  meets  ks 
tequitemetks  becomu  much  mote  problematic  wkh 
increuing  size  of  the  software.  The  development  of  software 
for  any  nun-trivial  system  will  involve  a  number  of  stagu  of 
specification  and  duigi  refinemerk.  It  is  therefore  not 
practicable  to  verify  or  validate  the  code  directly  agrunst  the 
requiremeik  in  a  comptebeuive  and  complete  manner. 
Consequetkly  this  objective  hu  to  be  achieved  by  verifying 
each  stage  of  duign  refinemeik  against  the  pteviow  level. 
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The  approach  taken  on  this  project  wu  efiectively  that 
defined  under  Def  Stan  00-55.  In  particular,  to  meet  the  first 
tequtremetk  of  euuring  the  correctneu  of  the  requirements 
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ipeeifieaiian.  it  had  bean  decided  lo  uee  formal  medioda  of 
aofoMre  apecificatiM.  To  meet  (he  Mooed  requiremeel  of 
enautieg  that  aubaequeet  atagea  of  developmeet  meet  the 
pNoedinc  onea  it  waa  decided  to  um  atatic  analyaia  to  verify, 
aa  rigotoualy  aa  poaaMe,  that  the  code  ukiiiialely  met  ita 
nquiremeata.  Dynamic  teating  waa  alao  to  be  uaed,  at  a  unit 
aad  ayalem  level,  to  provide  the  final  demonatration  of 
Amctionality  of  the  final  embedded  code.  Overall,  however, 
what  waa  planned  waa  to  integrate  all  three  of  thero  activitiea 
to  maximiM  confidence  in  the  aoftwaie  and  to  minimiM  the 
amount  of  effort  involved  in  each.  The  following  aectiona 
deacrfoe  the  woifc  carried  under  each  activity. 


S.  FORMAL  SPECIFICATION 

Ponnal  Methoda  of  aoftwaie  apecification  involve  the  um  of 
mathematica  to  lepicaent  the  apecification  for  the  rollware, 
typically  at  the  requiiementa  level.  The  'raiaon  d'etre'  of 
auch  methotfo  ia  that  it  ia  oonaidered  that  natural  language  (eg 
Engliah)  ia  too  im|MeciM  and  prone  to  ambiguity  to  be  able  to 
define,  accuralely,  the  required  behaviour  of  the  ayatem. 
There  are  numeroua  eaamplea  of  errora  introduced  into 
ayatcma  aa  a  reauk  of  miaunderatandinga  between  uaera  and 
implemcnton,  originating  from  ambiguitiea,  errora  or 
omiaaiona  in  the  requiiementa  apecification. 

The  UM  of  mathematica  can  help  to  eliminate  auch  cauaea  of 
errora  aince  preciM  rdationah^  and  requiiementa  are  defined 
aa  a  conaequence.  It  ia  alao  argued  that  the  um  of  auch 
(eehniquea  puta  Software  Engineering  on  an  equivalent  level 
to  other  engineering  diacipUnea,  inatead  of  being  more  of  a 
'craft'.  Conaequeotly  a  number  of  Formal  Methoda 
techniquca  have  been  originated  and  uaed  over  the  laat  few 
yean.  There  are  a  number  of  different  typea  of  auch 
methoda,  for  example  aome  um  act  theory  and  predicate  logic, 
othera  um  algebraic  equationa  and  othera  are  proceaa  baaed. 
They  all  have  an  agreed  notation  in  mathematical  terma,  have 
a  formal  calcutua  for  leaaoning  about  atatementa  and  enable 
argumenta  to  be  conatructed.  The  more  eatabliahed  methoda, 
auch  aa  VDM,  Z  and  OBI  alao  have  tool  aupport  for  aaaiating 
with  a3fntax  and  conaiateiicy  checking. 

On  thia  project,  the  manufacturer  had  realiaed  that  there  waa 
a  need  for  a  formal  apecification  if  the  aoftware  waa  to 
conform  to  Def  Stan  00-SS.  They  had  therefore  produced 
their  own  apecification  written  in  Z.  Thia  had  been  produced 
after  the  implementation  by  romeone  who  had  been  on  a  Z 
courM  but  waa  not  a  formal  methoda  expert.  The  outcome 
waa  a  apecification  that  waa  not  required  for  progreaaing  the 
deaign  (aince  thia  waa  already  completed)  but  waa  alao  not 
particularly  auilable  for  verification  and  proof.  The  fiiat  taak 
for  TA  Conauhancy  Setvicea  waa  therefore  to  produce  a  new 
Z  apecification. 

It  WM  decided  to  produce  the  Formal  Specification  in  a  object 
oriented  form  of  Z  originated  at  Surrey  Univetaity.  It  waa 
decided  to  um  thia  particular  method,  known  aa  Object 
Orientated  Proceaa  ^ireification  (OOPS)’,  firatly  becauM  of 
TA  Conauhancy  Servioea'  bmiliarity  with  it  but  abo  becauM 
it  allowa  Z  apecificationa  to  be  amaller  and  more  manageable 
than  might  otherwiM  be  the  care.  One  of  the  featurea  of 


OOPS  ia  that  k  poaacaaea  a  'reat  unchanged'  rule  whereby, 
unlike  atandard  Z,  one  doea  not  have  to  re-atale  all  thoM 
relatiooahipa  that  have  not  changed  ainoe  the  previoua 
expteaaion.  h  waa  conaidered  that  thia  would  ferilhatr 
aubaequent  proof  of  the  code  againat  the  qwcification. 

There  were  no  toola  available  to  aupport  OOPS  m  none  waa 
uaed  during  the  developmeot  of  the  formal  apecification. 
However,  aince  at  the  time  of  conducting  the  work  there  were 
few,  if  any,  Z-baaed  toola  available  (eg  ayntax  checkera)  for 
any  other  varianta  of  Z,  thia  waa  not  oonaidered  to  be  a 
aignificant  foctor  in  the  choice  of  Z  valiant. 

The  OOPS  apecification  waa  baaed  on  the  originnl  Z 
apecification  and  waa  atnictuied  to  follow  (he  original 
requiremeota,  rather  than  tiy  and  be  atnictured  in  a  way  that 
would  reflect  the  deaign  and  implcmcntatioo  of  the  code. 
Although  it  waa  appreciated  that  thia  would  not  aaaiat  in  the 
'proof  of  the  code  againat  the  apecification,  it  waa  oonaidered 
that  atructuringthe  Z  apecification  to  follow  the  requinmenta 
would  facilitatr  the  initial  atage  of  cnauring  that  the  formal 
apecification  accurately  reflected  the  atated  requiremenla  for 
(he  ayatem.  Where  poaafole,  though,  objecta  were  choaen  that 
reflected  the  known  architecture  of  the  implemeotation  if  thia 
waa  conaidered  likely  to  fimilhatc  the  aubaequent  analyaia 
whhout  compromiaing  the  'atrict'  repreacatation  of  the 
requiiementa. 

The  next  deciaion  to  be  taken  waa  the  level  of  abatnetion  of 
the  apecification.  Typically  foimal  apecificationa  at  a 
requiremeota  level  ahould  be  produced  at  a  high  level  of 
abatnetion  and  then  progreaaively  refined  down  through  the 
deaign,  adding  implemeatalioa  detail,  until  the  code  level  ia 
reached.  In  thia  care,  becauM  it  waa  a  very  amall  ayalem 
(SOO  linea),  and  becauM  refinement  into  a  deaign  waa  not 
required,  it  wu  decided  to  produce  the  OOPS  apecificatkm 
at  an  intermediate  level  of  abatnetion.  Thia  would  provide 
an  ability  to  verify  or  prove  the  code  againat  the  apecification 
with  the  minimum  amount  of  levela  of  refinement  neoeaaary. 

The  OOPS  apecification  document  waa  produced  contaming 
the  formal  Z  achemaa  and  an  Engliah  language  commeotaiy. 
Defence  Standard  00-55  calla  for  animation  of  the  formal 
apecification  in  order  to  'validate'  h,  however,  it  waa 
conaidered  that  thia  waa  not  neceaaary  in  thia  caM  becauM  of 
(he  amall  aize  of  the  ayatem.  Inatead  the  OOPS  apecification 
waa  validated  by  a  aeriea  of  formal  review  meetinga  held 
between  the  aolhvare  manubeturer  and  TA  Conauhancy 
Servicea. 

The  production  of  the  formal  apecificatioo  and  the  reviewa  of 
it  were  found  to  be  urefiil  in  clarifying  detaila  of  aomeaapecta 
of  the  requiiementa  and  in  raiaing  rome  potential  probletna. 
In  particular  the  aoftware  performed  a  number  of  time 
dependeitt activitiea  to  enablek  to  obtain  lynchroniaation  with 
the  controlling  aignal.  The  review  activitiea  proved  to  be 
uMftil  in  clarifying  detaila  of  the  required  operation  of  thia 
part  of  the  roftware  and  alao  auggeated  that  thia  could  be  an 
area  where  the  implemenlation  may  have  diflicuky  in  meeting 
the  requiiementa. 
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OaM  it  had  bcoa  praduead  aad  revkwwd  baiag  'comet' 
the  feroHl  nMcifiwdinti  wu  dm  uced  m  the  iailial  point  for 
Ihn  Coinpttiim  Ana^rsie  dwetfoed  under  Malic  analytii 
bekw. 


«.  STA'nc  VEuncA’noN 

dJ  Barfctroend 

Hie  UK  Miniatfy  of  Defcaoe  haa,  for  many  yean,  required 
the  uae  of  Malic  anelyak  on  aafoty  critical  aiihonie  aoforare. 
Thia  requirement  originaled  from  ooncema  in  the  late  1970i 
that  dynamic  teating  wea  inaulficieni  to  provide  compleic 
confidence  in  the  eorrectneaa  of  aoftware.  Thia  waa  becauac 
of  the  known  inahiliQf  of  teMing  to  provide  compietc.  coverage 
of  all  poaaibfc  patha  through  any  non-lrivial  piece  of  aoltware. 
Tolling  can  therefore  only  ihow  the  preaence  of  fouka,  not 
their  abaence. 

Aa  a  reauk  of  thia  ooocem,  reaearch  waa  commenced  into 
mMhoda  of  analyaing  aoltware,  uakg  mathematical 
leebniqum,  initially  to  inveiligate  the  Miticture  of  the  code. 
A  nunfoer  of  toola  were  produced  from  thia  reaearch,  one  of 
which  waa  MAL,PAS.  llie  aim  of  theae  atatic  analyaia  toola 
waa,  uaing  analyaia  rather  than  execudon,  fiiMly  to  reveal 
potential  erron  in  the  aoltware  and  leoondly  to  pennk  the 
rigoroua  verification  of  code  agaioM  ipecificalioni. 


fa  What  k  Stnlfe  Anatyafo? 

Static  Analyaia  ii  a  very  widely  uaed  term  which  meani 
different  thinga  to  diffieraM  people.  At  ka  limpleM  level. 
Malic  analyaia  il  the  examination  of  code  without  the 
execution  of  the  code.  In  auch  terma  even  code  waUcthroughi 
can  be  conaidered  u  a  form  of  atatic  analyaia.  More  typically 
atatic  analyaia  k  performed  by  aoftware  took  but  theae  again 
provide  a  wide  range  of  difiereat  typea  of  analyak.  In  broad 
terma,  however,  it  k  poaiible  to  identify  four  main  fypea  of 
analyik  namely  Melrica  Aiulyik,  Flow  Analyak,  Semantic 
Analyak  and  Complknce  Aiulyak.  There  k  by  no  meana 
univenal  agreement  on  theae  cat^oriei  or  theae  namea  but, 
for  the  purpoaea  of  ihk  paper  one  can  define  each  aa  followi: 

6.2.1  hfetrics  Amafysis 

Thk  form  of  atatic  analyak  k  perfoimed  by  a  number  of  well 
known  took  and  aimi  to  provide  Ggurea  that  give  an 
indication  of  the  'quality'  of  the  loutce  code.  Typical  figurea 
that  are  produced  include  the  number  of  linea  in  each  program 
aection/ptocedure,  the  nunfoer  of  patha  through  each  program 
aeciion,  the  ratio  of  comment  linea  to  executable  linea  and 
figurea  defining  the  complexity  of  the  code  oonitructa. 
Somelhnea  the  took  are  abo  able  to  identify  and  flag  uiage  of 
particular  code  coawtriiGta  that  can  help  in  enauring  that  coding 
codei  of  practicea  have  been  followed. 

Such  analyaea  tend  to  be  quick,  and  therefore  cheap  to 
perform.  WhilM  they  give  an  indication  of  the  broad  qinlity 
of  a  piece  of  code,  thk  k  no  guarantee  at  all  that  the  code  k 
conect.  Indeed  aubitantial  judgement  may  be  required  in 


interpreting  the  rreiiki.  For  example  there  may  be  good 
reaaona  why  a  paitiwikr  procedure  k  many  timea  longer  than 
the  ideal  kntfh  of  around  SO  linm  of  louroe  code.  Saailarty 
whilM  k  may  be  of  inicnat  to  know  which  are  the  moM 
complex  eectkme  of  code,  theae  may  not  be  the  moM  critical 
from  a  fimctinnnlity  point  of  view  and  by  fttctiiing  eWiwtinn 
on  ooraplexky  one  may  be  divmted  from  the  main  kaum  of 
crkicalky  and  correctneae. 

6.2.2  fiowAMafysis 

Thk  analyak  concentratea  on  the  Bow  of  control,  data  and 
informatioo  through  the  code,  h  reveak  thk  to  the  uaer  in  an 
appropriate  dcacriptivc  form,  highlighting  where  appropriate, 
pntentkl  anomalim  in  each  of  the  typm  of  flow. 

For  example  a  graph  of  the  control  flow  of  each  procedure  k 
often  dkpiayed  along  wkh  an  identification  of  paifictikr 
fealurm,  auch  aa  the  localioo  of  loopa,  entry  and  e^  poinli. 
The  took  may  be  able  to  provide  a  atatement  of  wheito  the 
code  k  well  alnictured  (eg  according  to  ruka  defined  by 
DiikMta)  or  badly  atructured.  Of  moM  importance  k  the 
identification  of  any  uniafe  featuree  auch  aa  dynamic  haka 
and  loopa  wkh  mukiple  enliiea.  h  may  ako  be  poaakde  for 
any  aynlactically  unreachabk  or  redundant  code  to  be 
identified. 

Analyak  of  the  data  uiage  of  code  can  provide  informatioo  to 
the  uaer  that  can  be  uaed  to  check  againM  the  required  data 
uaage  aa  defined  in  a  low  level  ipecification.  Additionally 
auch  analyak  can  explickly  identify  data  uaage  anomaliea  that 
could  be  an  indication  of  aoftware  erroia.  Typical  data  uaage 
infonnMion  provided  inehidea  an  identification  of  which 
paramctera  are  read  and  which  are  written  and  thk  can  be 
checked  agunM  input/output  liita  defined  in  the  tpccificalion 
in  order  to  verify  the  conectneaa  of  there  aapecta  of  the  code 
and  ipecificatiooi.  The  loit  of  anomaliea  highlighted  can 
include  IN  parameten  wrkten  to  (which  may  indicate  bad 
programming  piacliee)  and  OUT  paramctera  never  written. 
Sometimea  the  uaer  can  define  to  the  tool  what  the  eiqwcled 
data  uaage  k  for  the  program  aection  and  the  tool  will  then 
identify  whether  thk  k  in  foot  the  care. 

Finally  within  thk  category  k  analyak  which  provide!  detaik 
of  the  information  flow  through  the  code  and  an  indication  of 
the  dependencki  between  data  kema.  For  example  the 
analyak  may  identify  which  inputa  affect  which  output!. 
Such  reauka  can  be  uaed  to  check,  from  knowledge  of  the 
ipecification,  that  there  are  no  unexpected  dependenciea  or 
mkaing  dependenciea.  Thk  lott  of  analyak  may  be  moM 
lukable  for  lecurky  critical  code  where  k  may  be  of 
particular  importance  to  enaure  that  apecific  ouq>uta  are  only 
affected  by  defined  inputa. 

Flow  analyak  k  particularly  uaefol  for  enauring  conectneaa 
ofdteaynlaxoflhecode,  for  checking  that  the  correct  inputa 
are  paaaed  in  and  out  and  for  identifying  potential  errori  in 
the  flow  of  control  and  the  uaage  of  data.  To  lome  extent 
aome  of  there  kauea  are  checked  or  protected  againM  through 
the  uae  of  'good'  high  level  language!,  auch  aa  Ada,  and 
'Mriot'  compileri.  Even  ao  the  numbox  of  anomaliea 
revealed  by  auch  analyaea  can  be  high  and  can  aave 


4r 


•  • 


•  • 
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wJirtinriil  Mnwiate  of  tiow  tad  ofloil  if  iWiccted  at  an  cariy 
Mi(a.  However,  rack  analyaes  caoDot  cheek  that  the  code 
iweieg  or  iiaiiinrtri  ate  oomct.  For  this  oee  needa  to  uae 
iwnintic  or  conudianoe  a—lyaie. 

AZS  StmoHrtc  Amafynis 

lianantir  Aattyeie,  aometiiiiea  known  aa  aymbolic  eaecution, 
invoNaa  the  cheeking  of  the  aemwtica  of  each  path  through 
a  program  aeeiion/procedure.  Typically  aophiaticated  toola, 
of  which  there  are  fcw,  are  uaed  to  detail  the  preciae 
mnthranatiral  relatinnahip  between  program  aectioninputa  and 
outputa  for  each  path  through  that  program  aectioa.  UauaUy 
the  reauka  are  espreaaed  in  terma  of  a  path  condition,  or 
predioatB,  defitung  the  leiatmnahip  between  inputa  neceaaary 
for  the  particular  path  to  be  ejtecuted.  Functional 
rdatinnehipa  are  then  defined  between  the  inputa  and  ouiputa 
for  that  path.  Sometiinec  the  reauka  can  be  preaented  in  a 
tabular  form,  aa  a  truth  table*. 

The  eflect  of  aemantic  analyaia  ia  to  reveal,  for  the  rvhole 
range  of  input  variabfca  for  each  program  aeetion,  exactly 
what  the  code  doea  in  all  circumataaoca.  The  uaer  can  then 
check  thia  information  to  enaure  that  the  aokware  pcrfonna 
correctly  and  meeta  ka  apecificaiion.  A  aignificant  benefit  of 
thia  form  of  analyaia  ia  that  it  involvea  turning  the  aeqimrtial, 
and  potwUially  confiiaing,  logic  of  aouroe  code  into  parallel 
logie.  By  ahowing  rriationahipa  in  terma  of  inpub  and 
outputa  many  enora  have  typically  been  revealed  ia  terma  of 
unexpected  patha,  inoonect  relationahipa  and  even  mcorrect 
apecificationa. 

However,  even  with  toola  providing  the  reprraentation  of  the 
code  aemantica  on  a  path-by  path  form,  there  ia  atiU  the  need 
for  aiihatanrial  human  involvement  in  comparing  the  toola 
output  with  the  apecification  for  the  aoftware  and  deciding 
whether  the  two  agree.  A  reduction  on  the  human 
involvenient,  and  aa  increaae  in  tiie  tool-oaaiated  verification 
of  the  code  ia  provided  by  Compliance  Analyaia. 

6.2.4  CcmpSamc*  Amifysii 

CompHaitee  Analyaia  aima  to  ahow,  in  aa  automated  maimer, 
aa  poaafole  that  the  code  meeta  ka  apecification.  In  order  to 
be  able  to  do  thia  k  ia  neceaaary  to  define  the  apecification  for 
each  program  aeetion  preciaely;  thia  ia  uaualty  done  in  a 
mathematical  form  uaing  predicate  logie.  In  particular  the 
apecification  may  be  embedded  in  the  code  aa  FKB  condkiana, 
defining  condkiona  on  the  inputa,  and  POST  condkiona 
defining  required  relationahipa  between  inputa  and  outputa. 
Thoe  ia  alao  hkdy  to  be  die  need  for  aaaeitiona  entered 
within  the  code  to  define  kkennediate  requitementa,  for 
example  aa  loop  invatianta. 

Aker  embedding  the  qiecification  in  a  form  that  the  tool  can 
iiketpret,  the  analyaia  ia  conducted  uaing  a  combination  of 
toola  aaaiatance  and  analyat  direction.  The  role  of  the  aiudyat 
ia  tyjncally  to  provide  guidance  to  the  tool  in  the  choice  of 
rulea  and  relationahipa  that  ate  inviAed  whilat  ahowing 
conformance  between  the  code  and  qiecificationa.  Depending 
on  the  power  of  the  particular  tool  and  ka  aimplification 


abilky,  the  involvemenl  of  the  analyaia  may  be  very  large  or 
could  be  quite  me  deal. 

CompiiaoBe  Analyaia  ia  effectively  performing  a  proof  of  the 
code  «g***»u  a  low  level  ■»^>i>^»*>**«***t  in  thia 

reapecl  k  ia  by  for  the  moat  rigoroua  of  the  alalic  analyaia 
techniquea.  However,  due  ia  at  the  expenae  of  coat  becauae 
of  the  potentially  large  amount  of  analyat  effort  involved. 
Typically  Comphaaoe  Analyaia  produmivky  ia  around  aa 
order  of  magnitude  wotae  than  the  next  moat  rigoroua  form 
of  analyaia  (Semantic  Analyaia)  at  around  5  linea  per  man 
day.  One  therefore  haa  to  decide  whether  the  criticality  of 
the  code  juatifiea  thia  level  of  expenditure  or  whether  a  teat 
rigoroua  and  leaa  coady  form  of  analyait  can  be  uaed. 


dJ  Kequirfrti 

Having  originated  the  toola  that  perform  the  moat  rigoroua 
forma  of  atatic  analyaia,  namely  Semantic,  and  Compliance 
analyaia,  the  UK  Miniatiy  of  Defanee  haa  requealed  the  uae 
of  aueh  techniquea  on  aafety  critical  airborne  aoftware  for 
aome  years,  although  k  hat  not  been  mandated  in  a  aiandard 
imtil  receruly.  One  of  the  earlier  atandarda  in  the  MoD 
avionica  arena  mentioning  atatic  analyaia  techniquea  it  Interim 
Defence  Standard  00-31',  produced  in  19t7.  Thia  atandaid 
effectively  fotlowa  DO-178A  but,  amongat  oth^  thinga,  abo 
requirea  the  uae  of  an  ’approved  analyait  prooeaa’  for  the 
verification  of  module  imptementation. 

In  practice  atatic  analyait,  iq>  to  and  including  Semantic 
Analytic,  baa  been  carried  out  on  moat  airborne  UK  milkary 
ufety  crkica)  ayatema,  almoat  invariably  aa  an  indepcadent, 
poat  developmeik,  verification  taak.  Experieooe  haa  ahown 
the  benefiix  of  the  uae  of  theae  techniquea.  even  if  th^  have 
leptcaerked  aa  irrecoverable  coat  at  the  end  of  the 
developmeik  programme.  Conacquently  there  are  continuing 
and  incieaaiag  requiiemema  for  aucb  work  U>  be  conducted  on 
all  aafety  critierd  MoD  ayatema,  to  the  extent  that  Interim  Def 
Stan  00-53  abo  calb  for  Compliance  analyab. 


d.4  Auiyib  Conducted 

In  order  to  meet  the  requiiemeikt  of  Def  Stan  00-55  on  thb 
project  k  waa  decided  to  cany  out  three  main  forma  of  atatic 
analyab,  namely  Flow  Analyab,  Scmaikac  Analyab  and 
Conytiance  Analyab.  Some  melrica  were  produced  aa  part 
of  thb  Maiyab  but  k  waa  iMt  conaideied  neceatary  to 
apeeifically  analyae  and  aaaeaa  the  ’quality’  aqiecia  of  the 
code  ainoe  formal  verification  would  go  oonaiderably  beyond 
any  btuea  of  quality. 

k  waa  decided  to  uae  MALPAS  for  thb  work  aince  thb  b  the 
tool  wkh  which  TA  Conaukancy  Setvioea  are  moat  fiunilbr. 
ft  b  abo  more  tuked  to  retroapective  verification  than  other 
limibr  toote.  In  order  to  perform  auch  analyab  MALPAS 
requirea  the  aourcc  code  to  be  traiulated  into  MALPAS  IL 
(Irkennedbte  Language)  which  b  the  input  bnguage  for  the 
tool.  Often  thb  b  rlone  automatically  uaing  one  of  a  number 
of  autoiiMtic  tranalatora  that  exbt  for  a  range  of  languagea. 
Hmwever,  in  thb  caae,  amce  a  translator  for  6805  aaacnibler 
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did  «at  aii«  at  Itw  tim  mhI  tinee  ihci*  VMM  MMtlfieicnl  eodc 
to  be  tfoaotaiad  to  jugtiiy  the  ttevdopoMUt  of  •  tnaeletor, 
bond  tnuMklioa  wm  itaed. 

1.4.1  ThauJaCieM 

The  iniliBl  tUfs  of  my  hood  tieneletinw  pracMo  ie  to  define 
the  weminiii  between  the  eouroe  lengueje  and  IL,  the 
MALPAS  iofui  hntiwue.  IL  bee  e  tupcrfieial  reaemUanee 
to  PMcelor  Ada  but  aleo  ooolaina  oaoMrueU  that  allow  it  to 
be  uaed  bt  the  modelliog  of  bw  level  bumaigce.  Mapping! 
were  defined  bcltveen  6805  aaaeeebier  and  IL  for  all  the 
inatnictiana  and  adifaeaaing  modea  uaed  in  the  code  to  be 
analyaed. 

TA  Conaukancy  Servioea  have  aubatantial  expenenoe  in  the 
derivation  of  mappinga  and  the  production  of  tranalatora  and 
thia  waa  uaed  to  obtain  an  appropriate  oompromiae  between 
abatiaotion  and  preeiaion  which  would  foeililate  analyaia  whiat 
enaunig  oorrectneaa  of  mndelling.  The  mapping!  were 
deaigned  ao  that  they  pennitted  the  riuirbing  of  a  number  of 
featurea  of  aaaembler  code  (auch  aa  alinaing  and  overflow)  that 
are  known  from  eapermnee  to  be  the  potential  aouroe  of 
errora  in  the  code.  The  mapping!  were  defined  in  a  mapping 
document  which  went  throi^  a  number  of  alagea  of  foimal 
review  in  order  to  cnaure  oorrectneaa  and  aukability. 

6.4.2  Anafysu  Control 

TA  Conaukancy  Servioea*  experience  with  thia  form  of 
analyaia  ia  that  k  it  raaenrial  that  the  leauka  are  reproducible 
and  cooaiatein.  Thia  ia  paiticulariy  true  of  large  project! 
where  there  are  large  numbeia  of  analyata  working  together 
but  k  ia  alao  relevant  for  imall  project!  auch  aa  thia  where 
analyaea  may  need  to  be  re-tun  at  a  later  date,  poaaibly  uaing 
diflerent  people. 

Cooaequently  TA  Conaukancy  Service!  have  defined  their 
own  'Standard!  and  Procedure!*  for  thia  form  of  work.  Thia 
document,  analogoua  to  a  coding  code  of  practice  for  aoftwate 
development,  definea  the  preciae  way  in  which  the  tool  will 
be  tun,  bow  the  configutaflon  control  aapecta  will  be  managed 
and  the  teauka  recorded  and  ratted.  A  further  feature  ia  a 
requiremeat  for  formal  reviewa  of  all  atudyaii  work,  the  aim 
of  which  ia  to  try  to  eluninale  any  poaafoilky  of  human  error 
in  thoae  paita  of  the  work  where  manual  mterpreution  ia 
neoeaaary. 

Additionally,  a  aetieaof  forma,  developed  by  TA  Conaukancy 
Servioea,  were  uaed  on  thia  taak  for  recording  the  analytic 
teauka.  *1110  particular  benefita  of  auch  forma  ate,  fitatly,  that 
they  permk  the  recording  of  the  analyat'a  inlerptetatioa  of  the 
analyaia  teauka  and,  aecondly,  that  they  provide  a  valuable 
verification  record  that  may  be  uaed  by  a  certificating 
authority  fi>r  checking  on  the  effectiveoeaa  of  the  work  carried 
out 


6.4.3  Flow  md  Stmmric  Anafytit 

Theae  analyaea  were  conducted  in  a  bottom-up  matwer  on  a 
procedure  by  procedure  haaia.  That  ia  to  aay  that  the  loweat 
level  prooedurea/aubroutineathat  call  no  olbeta  were  initially 
analyaed.  Theae  were  then  repteaenied  aa  MALPAS  IL 
procedure  mterfece  apecificatimw  which  theraaeivea  arc 
aufomaticatty  auhatkmrid  in  by  MALPAS  at  the  procedure 
catt.  Thia  feature  of  the  tool  prevent!  an  exponential  build  up 
in  complexity  aa  the  analyaia  ptogteaaea  up  the  calling 
hierarchy  and  permka  the  analyat  to  cotttrol  the  refevaitt 
information  paaaed  up  to  higher  levela.  In  thia  particular 
oaae,  becauae  of  the  tmall  aixe  of  the  aokware  there  waa  little 
ealliog  hierarehy  and  the  overall  analyaia  waa  conducted  in 
very  few  alagm. 

Ihe  analyaia  wu  eonducled  a  procedure  aectioo  at  a  tune  and 
the  teauka  compared  againat  both  the  intermediate  level 
natural  language  apecification  and  the  embedded  code 
cofflinenta  that  icpreacnted  the  low  level  apecification.  k 
could  be  argued  that  Semantic  Atudyaia  may  not  be  atrictly 
neoeaaaty  where  Complianoe  analytic  it  alao  being  conducted 
ainee  the  Compliance  Analyaia  perfotma  a  more  rigotout 
verification  of  die  code  againat  apecificationa.  However,  the 
Cotigdiance  analyaia  verifiea  that  the  code  meeta  the 
apecification  provided  but  will  not  identify  whether  the  code 
alao  perfotma  other  fimcliona.  Semantic  analyaia  will  reveal 
all  the  functionality  of  the  code  and  permk  identification  of 
any  fimctfonalky  adiikinnal  to  that  given  ia  the  apecification. 
h  waa  therefore  conaidered  neceaaary  to  perform  .Sciiwurtic 
analyaia  at  well  u  Complianoe  Analyaia  in  thia  caae. 

An  example  output  from  the  analyaia  it  ahown  below  in  figure 
1,  demonatrating  the  tabular  form  of  the  aemantic  output 
Thia  example  leprcacnta  a  aectioo  of  code  containing  five 
aemantically  poi^le  patha  from  the  aelf-deatruct  ayatem 
aoftwate.  The  firat  part  of  the  teauka  ahown  givea  aome 
exampiea  of  predicatea  (expreationa  on  input  variable!) 
making  up  the  path  condkiona  through  the  code.  The  aeoond 
aectiott  givea  exampiea  of  actiona  (relationahipa  between 
inpula  and  output!  for  each  ouqwt)  for  output  variablea 
wtittea  to  in  tto  aection  of  code.  Fuially  the  patha  table 
detail!  the  condkiona  neceaaary  for  each  path  to  be  executed 
and  identifiea  the  aatignmema  to  each  of  the  ouqwt  variablea. 
One  point  of  note  in  thia  example  ia  that  a  number  of  the 
output  variablea,  for  example  opcomp  and  nr,  are  aaaigned 
the  tame  expreation,  irreapective  of  which  path  through  the 
code  ia  executed. 

All  anomalka  ftiund  during  thia  analyaia  were  documented, 
calegoriaed  and  repotted  to  the  aoftwate  manufiuxure  for 
diacuaaion  and  reaolution.  Thia  aapect  ia  diacuaied  in  mote 
detail  in  aection  6.3  below. 


•  • 
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C2;  opoMi 

•  aslbit_iet_bilclr  (biMr,  eount_h,  oouat_l, 
opcoii4>_h,  opcompj,  priibtto,  iiiiie_h, 
M,  ttr_h,  ltr_l) 

C4:  piM(2)  >  pM  (ciiip6_Mt_H  (3t,  iulbit_Ml_i{il 

(ip_l.  poiUi,  pilibao,  tiaw_h,  time_l))) 

C6:  aSre  •  klemd 

C7:  «  cpoia 

Actioiii 

AMignmentt  to  bitoir 


The  CompliMM  Aaaisfni  Ml  ooadiiolad  iadepaBdaa^  of  te 
Flow  lod  ^WHiilir  AailyiM.  Ai  hn  been  deicribed  ■ 
•eeliaa  6.2.4  aboive.  the  fini  uA  ww  to  pcoduoe  the 
lenM  of  PKE  iad  POST 
eoa^tiom,  lad  lay  iwMiiiy  ASSERT  ititmirti.  from  the 
OOFS  ipeeifieKiM.  The  initiel  Mige  w«i  Ihceefore  to  tefiae 
the  OOFS  ^wwilicelina  down  to  die  leipiired  kiw  level 
flMdhcMtieil  ^leetficeltoo. 

Thie  refiaeaieat  wu  perfomed  minuelly  but  in  u  riforouefy 
•  meaner  le  poeiftle,  with  ill  the  lefinement  woHt  being 
reviewed.  The  fcUowing  ilhieintion  ehowi  how  in  ibetnct 
Meleneat  widun  dm  OOFS  ipeeifieetioa  ie  refined  to  dud  it 
ii  fipiMealed  in  imam  end  ftmcdoiiB  that  appev  widiai  dm  IL 
treneletion  of  the  eouree  code. 


All 

nztbit_iet_bitctr  (bitetr, 
couat_b,  count_l,  opcomp_h, 
opooatti_l,  pthbtto,  time_h, 
time_l,  tar,  ttr_h,  ttr_l) 

A12 

0 

Aaaignmenia  to  tatemd 

A21 

nonvaU 

A22 

afire 

Thie  pai<icullre«imple  of  the  implrmmtitinn  inteffimee  with 
dm  microproccaeore  herdwaie  time  lyetem  to  obtain  icoeee  to 
timiiig  mfonnition.  Tbia  ia  modelled  in  the  aaalytie  by 
intmdiiciing  the  eperifiration  variable,  murjimt.  The 
refinement  here  iavolvee  turning  an  abetiact  toleeaace 
ooodilioa  into  a  detailed  expreaaioo  at  the  level  of  aaaembler 
anchmetie  and  Mt  maaipulatioaa. 

Cooaider  the  refinement  of  dm  dming  condition 

•vaKl)  -  tt  >  •  tol  (125)’:- 


Aaaignmenta  to  tinm_h 
A51 


AS2 


timeri_aet_timeh  (timc_h, 
time  1,  prbbtto) 

0 


Where  tol  relatea  to  a  tolerance  on  the  apecified  lime  in 
mieroeeoonda.  In  due  caae  one  ia  interceted  in  the  topmoat 
limit,  choaon  Co  be  I40|ia.  Refinement  fiiom  thia  into  dm 
variablea  uaed  in  the  code,  uaiag  the  knowledge  that  2  eycka 
Ipa,  givee  the  following: 


•  • 


Aaaignnmota  to  time_l 


A61 

timera_ 

_aet_timel  (time 

-h. 

time_l,  prhbtto) 

A62 

0 

Ptths  Table 

Conditaona 

pubs 

1 

2 

2 

4 

5 

Cl 

9 

9 

9 

F 

P 

C3 

f 

T 

T 

T 

C3 

9 

T 

C4 

r 

P 

T 

CS 

T 

P 

Ci 

P 

C7 

P 

ct 

T 

Ail 

Ait 

All 

All 

An 

iNMt 

A21 

A3t 

AS 

PMB 

A91 

A3S 

A91 

A» 

forth 

A4t 

A4I 

AO 

AO 

AM 

A5I 

A51 

A5B 

ASI 

ASI 

ACI 

AM 

Afi 

Ail 

AM 

by 

ATI 

ATI 

ATI 

ATI 

ATI 

bj 

AM 

An 

ASI 

All 

All 

AM 

AM 

AM 

AM 

AM 

Mr.l 

AMI 

Aim 

AMI 

AIM 

m 

<Voaaf_k 

AIM 

Alii 

Alii 

Alll 

m 

Al» 

Ain 

Ain 

A121 

/a 

val(t)  -  tt  >  -  tol  (125) 
val(t)  -  tt  >  -  140 

opcomp  w  ttr  140  tar  ^  inatr_time  >  »  280 

turn  (opoomp_l,  opcomp_h)  • 

phie  (aum  (ttr_l,  ttr_b),  aum  (70,0))  AND 
bit  (6,  tar)  •  1  AND  inatr_time  >  280 

Aa  waa  nmatfoaed  in  aeclion  5  above,  dm  atructuiing  uaed  in 
dm  deaign  did  not  reflect  the  natural  atnictuiing  of  dm 
apecificatioo.  In  particular,  the  impiemented  proced urea  often 
contained  the  behnviourial  fimctionality  of  a  nundmr  of 
operatioai  in  dm  apecification.  Thia  complicated  the  analyeia 
and  nmana  that  nunmtoua  ASSERT  atatementa  had  to  be  uaed 
to  relate  the  code  to  dm  qmcification. 

The  MALFAS  ComplianoeAnalyeerwoika  by  comparing  dm 
code  againat  dm  embedded  qmcification  and  expliciUy 
identifying  any  differenoea  between  dm  two.  Such  diffctencee 
are  identified  aa  a  threat;  hence  if  the  code  meeta  ka 
apecificatioo  the  threat  ia  declared  to  be  ’fidae’.  In  theory 
thia  operation  can  be  performed  entirely  automatically, 
however,  becauae  the  MALFAS  algebraic  ainqilifim’  ia  not 
alliiawerfiil,  manual  aaaiatance  ia  uaually  neceaaary.  Thia 
aaaiatanoe.  takea  the  form  of  imducing  replacement  rulea 
which  define  dm  aemantica  of  rulea  that  the  aimlyit  wiahea  to 


•  • 
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apply.  Theie  nikt  may  be  defieed  dwaclly  from  the  formal 
apeciftoartim  armaatiri  or  may  timpiy  expieaa  a  haadard 
matheamthial  wilatinnahip  that  the  aimpltfier  ie  imabk  to 
reengtiair  wilhoat  aaeiatanre. 


AMlyablaaidfr 

The  ouloome  from  each  part  of  alatic  aoalyaie  waa  eidier  that 
each  program  aectioa  waa  found  to  apree  with  ila  apecifieaiioo 
or  that  anomalim  were  diacoveied.  Theae  anomaliea  «wMild 
range  from  identified  code  ertors  through  to  commewta  on 
how  pattieular  aapeela  of  the  code  or  specifieatioaa  could  be 
improved.  In  common  with  other  ahnilar  analyaia  ptoiectf 
that  TA  Conaultaiiey  Servieea  have  conducted,  the  anomalim 
raiaed  were  categoriaed  in  terma  of  teriouaaeaa  by  the  analyat 
who  raiaed  the  problem. 

Three  categorim  of  anomalim  were  defined,  m  followa: 

A  Technical  error  or  omiaaion  cauaing  non¬ 
conformance  adth  ipecificatiao  which  may  have  a 
impact  oo  mfaty. 

B  An  ambiguity  or  tuapeet  dmiga  feature  of  leaaer 
aignificance  than  A  for  which  corrective  action  ia 
conaidered  deairable  though  not  caamtial. 

C  Obaervation  of  minor  aignificance.  No  inunediate 

action  ta  neccaaary. 

In  total  42  anomalim  were  raiaed  aa  a  rmuk  of  the  atatic 
analyaia,  of  which  10  were  category  A,  13  were  category  B 
and  19  were  eatery  C.  Thia  level  of  comment  ia  conaidered 
quite  good  bearing  in  mind  the  minimal  verification  and 
validataon  work  that  had  been  conducted  prior  to  TA 
Conaukancy  Setviem'  involvemeat.  Putthermore,  it  ia  only 
about  30%  worae  (in  tmma  of  anomalim  per  line  of  code) 
than  the  rale  repotted  by  TA  Conaultancy  Servieea  on 
auppoaedly  fiiUy  verified  code  on  a  number  of  other  projecta. 

It  ia  not  poaafok  to  my  what  proportioo  of  anomalim  waa 
dkcovmed  during  each  form  of  atatic  analyaia  becauae  of  the 
order  in  which  the  analyaia  waa  conducted.  For  exampk  the 
Semantic  and  Conqiliance  analyam  were  conducted  in  parallel 
to  aome  extent  to  aiurmalim  may  have  been  diacoveied  firat 
in  one  before  being  picked  up  in  the  other,  k  it  poaairk  to 
my  that  a  number  of  anomalim  relating  lo  timing  were 
identified  and  clarified  more  during  the  Compliance  Analyaia 
than  during  the  other  analyam.  Thk  wu  primarily  a 
conaequence  of  the  conceina  about  timing  that  were  firat 
appreciated  during  the  dmivation  of  the  OOPS  apecification. 
Aa  a  tcauk  of  tUa  concern  additional  modelling  of  timing 
aapecta  waa  performed  during  the  Complianoe  Analyaia  and 
led  to  the  probkma  becoming  fintber  defined. 

Following  the  reporting  of  the  anomalim  by  TA  Conaukancy 
Servieea,  each  one  wm  dkctiaaed  with  the  cualomer  and 
corrective  action  agreed.  Although  aome  anomalim  raiaed 
were  clear  cut  errora  or  deficienciea,  many  (aa  haa  comimmly 
been  found  in  other  projecta)  invotved  a  degree  of  aubjective 
judgement.  For  exampk  an  anomaly  may  be  raiaed  if  the 


code  waa  conaidered  mauffickmly  defenaive  but.  depending 
on  the  manufoctuicra  view  regarding  the  Hmlihnod  of  aa 
aocidmt  beiag  cauaed  by  the  lack  of  defenaiverMm,  the  code 
may  or  may  not  be  conecled. 

One  audt  raiaed  conernmd  a  tinmr  routme  which 

checked  lo  aee  whether  the  timer  had  rrarhrd  (and  equalled) 
the  fixed  timeout  value.  Akhough  the  pkoe  of  code  met  ka 
apecification,  aa  aruanaly  vma  raiaed  during  the  aaalyain 
which  auggmted  that  it  would  be  mfer  if  the  code  checked  for 
the  timer  being  equal  lo  or  greater  than  the  timeout  value. 
Thia  waa  agreed  by  the  manufocturer  and  the  appropriate 
aection  of  code  waa  changed. 

Overall,  aa  a  reauk  of  the  analyaia  12  code  changm  were 
made,  9  apeeificatinn  changm  wen  made  and  no  fiuther 
action  waa  taken  on  the  remairtder.  Thoae  for  uAich  rw 
action  wen  taken  wen  eilher  conuneala  regarding  poaaMe 
improvemerita  to  the  ayatem/aokwan  or  wen  conurtenta 
when  fiuther  clarification  from  the  mamifecturer,  poaaibly 
relating  to  lykem  kvel  protection  outaide  the  aoope  of  the 
aokwan,  waa  abk  to  alky  the  ooncerna  of  the  analyat. 


7.  DYNAMIC  VERinCATlON 

The  dynamic  verification  activity  waa  iplk  into  two  parta, 
oonaiating  of  momrk  teating  and  aykem  teatmg.  Becaun  of 
the  amall  tine  of  the  aokwan,  a  aepaiaie  mtegration  teating 
phaae  waa  not  applicabk.  Both  aeta  of  teat  wen  conducted 
uaing  a  hardwan  teat  rig  which  had  the  uaual  heilitim 
availabk  on  typical  m-circuk  emulalon. 

For  the  moduk  teating  a  act  of  leata  wen  defined  for  each 
moduk.  Then  conaiated  of  both  black  box  (firactional)  and 
white  box  (atructural)  teating.  However,  in  thk  can,  imtead 
of  uaing  detaik  of  the  aource  code  aa  a  meana  of  determining 
the  whke  box  leata,  the  Semantic  Analyak  rmuka  wen  uaed 
iostetd. 

The  black  box  tcala  wen  initially  defined  uaing  leehniqum  of 
equivaknee  paititionnig  (mid-value)  and  boundary  value 
analyak.  Mid-value  analyak  raandklly  involvm  the  choice 
of  vahrm  for  each  input  variabk  ao  that  ka  input  domain  k 
coveted.  Boundary  value  analyak  k  baaed  on  the  nation  that 
if  then  an  vmhim  when  the  value  of  a  componeik  changm, 
then  errora  of  coding  an  likely  to  be  made  in  the  handling  of 
thon  boundarim.  Hik  analyak  prooedun  Ihenfon  chooaea 
teat  data  on  or  near  thon  boundarim. 

The  teat  caam  for  the  black  box  teata  wen  choaen  uaing  then 
leehniqum  from  both  the  OOPS  qrecification  and  the 
mtermediate  level  natural  language  apecification.  Akhough 
the  OOPS  apecification  waa  at  the  ayalem  level,  the  amall  ake 
of  the  overall  nkwan  permkted  moduk  level  teat  caam  to  be 
choaen  from  titia  domiroeiit. 

The  aelection  of  the  teat  caam  for  white  box  teating  waa 
pmformed  by  uanig  the  Semorkic  Analyak  reauka  to  enaun 
that  all  patha  through  each  moduk  wen  tealed.  Thk  waa 
feoafokon  thk  project  becaun  of  the  rdatively  amall  ake  of 
each  of  the  modufea  and  the  anutil  numbetv  of  aemarkically 


•  • 


•  • 


I 


23-V 


pOMSite  |MtlM  dumtgli  Moh.  Since  the  black  box  Mi  would 
cover  •  rid»ift(iint  niahbcr  of  the  palhc  throusb  each  aioduk, 
thawhikiboxtcaiwerechotcBto  iiTplwnrnUhcae  and  cover 
die  MMiniog  palha. 


For  ihia  paitieular  problem  aKire  dolailed  twtim  aad 
invwari^linii  wm  able  lo  ideolify  why  the  partiwilar  problem 
wai  happeamp  and  to  unseal  a  chaape  m  value  of  a  lueeher 
of  tokum  paiametrn  to  rliminele  the  problem. 


1 

1 
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in  more  detail  the  way  that  the  whhe  box  tort  eaam  wae 
ohoaen  wae  to  aelect  the  mput  condkiaat  defined  by  the 
prediBate  fi>r  each  path  in  the  Semantic  Aaedyeia. 
Conaequently,  fiir  the  example  Semantic  Analyaia  output 
ehowa  in  figure  1,  path  1  would  be  exereiaed  by  acoing  the 
input  variabtm  euch  that  cemditiooe  1.  2  and  3  were  fitlae. 
The  individual  outpute  would  be  checked  on  the  lig  to  cnaure 
that  they  agreed  with  thoae  that  had  been  both  revealed  by 
analyaia  and  verified  againet  the  epecificatione. 

In  other  caaee,  for  example  where  the  Semantic  Analyaia 
abowed  that  there  were  loopa  or  other  break  pointa  in  the  code 
(for  example  lower  level  procedure  calla),  the  rcauka  of  the 
atatic  analyaia  would  be  uaed  to  deiennine  aukable  breakpointa 
in  the  code  at  which  execution  ahould  be  hailed  for  the 
inapection  of  utermediate  reaufca  and  the  lotting  of  new 
valuei.  For  aome  of  thia  work  a  number  of  code  inaerta  were 
neceaiary  to  act  aa  teat  atuba  to  capture  data. 

A  total  of  approximately  100  module  tecta  were  carried  out, 
which  gave  complete  path  teating  through  each  of  the 
modulea.  A  number  of  the  tcati  foiled  due  to  anomaliea  that 
had  been  diacoveted  during  atatic  aruUyaia,  however,  no 
additional,  previoualy  unknown  fouka  were  found  during  the 
module  teating. 

The  ayatem  tcata  were  deaigned  to  inveatigatc  the  behavioral 
aapecta  of  the  complete  aoftwiue  and  were  intended  to  provide 
aupporting  evidence  that  the  ayatem  aatiaSed  ita  top  level 
requirementa.  Theie  teata  were  therefore  clauified  at 
validation  and  black  box  teata  and  were  cboaen  fiom  the  top 
level  requirementa  ipecification  rather  than  any  of  the  tower 
level  apeciScatioiii  or  atatic  analyaia,  except  in  the  reapect  of 
timing. 

Aa  haa  been  mentioned  earlier,  there  had  been  concern,  right 
fiom  the  derivation  of  the  formal  apecification,  about  aapecta 
of  the  timing,  particularly  relating  to  interpretation  of  the 
input  aignal.  Akhough  theae  problema  had  been  inveatigated 
during  the  Compliance  analyaia,  auch  itauea  are  moat  eaaily 
inveatigated  during  dynamic  teating.  Conaequently  a  aet  of 
teata  waa  derived  for  inveatigating  and  quantifying  thia 
particular  problem  which  waa  largely  a  module  interfime  and 
integration  problem. 

The  cuhnirutfion  of  theae  teata  into  the  timing  iaauea  wu  to 
confirm  that  the  ayatem  waa  unable  to  meet  a  particular  aignal 
performance  pruaineter  that  had  been  act  in  the  original 
requirementa.  Thia  waa  not  conaidered  to  be  a  aignificant 
problem  aince,  firitly,  the  performance  figure  defined  had 
been  choaen  lomewhat  arbitrarily  and,  aecondly,  the  effect 
waa  foil  aafe.  However,  aince  with  a  ayatem  of  thia  aort  being 
more  fitil-aafe  than  intended  haa  the  oonaequence  of  cauaing 
deatruction  more  often  than  ia  atrictly  neceaaary,  there  were 
potemial  coat  iaauea  to  conaider. 


I.  CONCLUSMINS 

The  ultimate  juatification  of  the  uae  of  rigoroua  techniqum, 
auch  aa  thoae  deaeribed  in  thia  paper  ia  whether  the  ayatem  ia 
enor-fiee  in  aetvioe.  That  haa  been  abowa  to  be  the  caae  on 
that  project,  akhough  uae  of  the  ayatem  haa  been  very  Kmitnd 
to  date.  Ihere  ia  tharefore  no  atatiatical  evidence  ao  lar  to 
ahow  that  the  uae  of  auch  techniquea  have  been  beneficial. 
Indeed  it  will  newer  be  poaafole  to  lay  with  complete  certairdy 
that  the  aame  fieedom  fiom  oror  could  not  have  been 
juatified  uairig  ‘tradkinnal'  leia  rigoroua  tediaiquea. 

Howbvct,  the  uae  of  the  formal  apecification  and  the  rigoroua 
Italic  aiudyaia  did  reveal  erron  and  deficicnciea  in  the  code 
which,  without  their  correction,  would  have  ahnoat  certainly 
reauked  in  cnooeoua  operation  of  the  ayatem.  Furthermore 
the  uae  of  auch  rigoroua  techniqiira  haa  icrved  lo  give  a  high 
level  of  confidence  in  the  conectneaa  of  the  aoftware. 

The  aim  of  the  work  at  the  oulaet  waa  lo  provide  a 
oomprehenaive  analyaia  by  uaing  diaparate  tnchniqiina.  The 
uae  of  a  combinatioa  of  atatic  and  dynamic  activitiea  haa  been 
ahown  to  give  a  fiur  degree  of  overlapping,  combined  with 
maximal  coverage  of  the  problem  domain.  Where  the 
techniquea  overlap  there  ia  a  high  degree  of  croacchecking, 
Ihua  increaaing  confidence  ia  the  rcauka.  The  goal  of 
minimal  effort  haa  been  achieved  by  employing  the  different 
capabilkiea  of  the  techniquea.  In  particular  the  exteruive 
fiinctianal  behaviour  analyaia  afforded  by  atatic  analyaia 
coofoioed  with  the  d3fnamic  timing  analyaia  capabilitiea  of 
teating  haa  been  ahown  to  permit  the  inveatigation  of  all 
iaauea  without  enormoua  amounta  of  effort. 

The  work  haa  confirmed  the  value  of  formality,  at  leaat  on  a 
project  of  thia  aixe  where  the  operitioo  of  the  whole  a3ratem 
ia  at  a  level  where  k  can  be  underaloodby  a  aingle  individual 
without  apending  montha  of  time  learning  and  inveatigating 
the  ayatem.  It  haa  ahown  alao  that  rigoroua  verification  of  the 
code  againat  the  formal  apecification  ia  poaaible  uaing 
Compliance  Analyaia  techniquea  but  it  haa  illuatrited  that 
there  ate  aome  non-tigoroua,  manual  atagea  within  thia. 
Ferhapa,  becauae  of  thia,  the  work  haa  aerved  lo  emphaaiae 
the  likely  difficukiea  of  achieving  complete  proof  of 
oonectneaa  on  larger  ayatema  on  udiich  refinement  over  a 
number  of  levela  ia  likely  to  be  neceaaary. 

Fmally  there  ia  the  iaaue  of  coat.  Akhough  the  work  haa 
given  aa  high  a  level  of  confidence  in  the  correctneaa  of  the 
aoftware  aa  ia  cemaideaed  poaafole,  the  coata  have  been 
relatively  high  in  rebtion  to  the  aize  of  the  aoftware  and  the 
devetopmenl  coata  of  the  code.  However,  it  ia  conakfered 
that  much  of  the  coat  ia  a  conaequence  of  the  analyaia  being 
conducted  poat  development  and  alao,  fiom  having  to  be  re¬ 
done  following  changea  lo  the  aoftware. 
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k  it  coatidtred  ineviitbk  that  ooali  for  Ike  developmcat  tad 
veriftettioa  of  ttfoly  crkfotl  lokwoie  will  be  higher  ihaa 
thoee  for  aoo-erilioal  code,  eMiough  Ihii  it  Ukely  to  he 
recouped  in  tovingt  through  incretted  rditbilily  if  the 
toftwaie  hat  a  large  in-ietviee  life.  Nevertfadett,  tay 
additinnal  coat  for  auch  aokwaie  it  likely  to  be  tiay  indeed 
ooiapaiodlo  the  cotta  of  aay  potealial  aokware  foilueet  whisk 
OMy  be  expected  without  the  aikial  expenditure  on  tafety. 
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Discussioii 


Qwstiaa  H.LEDOEUFF 

Aoowbiwi<vyiiex»voM»letaroofltde|iro(liictiOB.<lev<riflcMloii.<levriiriMinnd'ai>ellogicielcritiqiie.«vcc  lamtdiode 
<|ue  vow  avez  ndliite.  (Mr  niipan  li  un  logiciei  tiniileaiau  cttcnikl? 

Refty 

Using  Irctokyirs  sndi  as  fonnal  meifaods,  the  early  costs  of  the  software  devdofmem  Ufe-cyde  will  be  higher  than  with 
“taditkinar  methods.  However,  savings  should  come  daring  later  stages  of  devdoimau  iBting  and  maintenance). 

Wether  these  methods  are  cost-effective  for  non-critical  code  depends  on  the  probiems  posed  by  software  errors 
encountered  m  service  and  wether  one  is  likely  to  encounter  rewort  cost  in  any  case  as  the  user  changes  his  mind  as  to 
what  he  wants  the  system  to  do. 

Question  C.  BENJAMIN 

Your  eflbrt  was  quite  small.  What  efforts  are  you  aware  of  are  doing  to  automate  the  formal  proof  of  the  spedficatioo? 
Reply 

There  are  a  number  of  individual  ptoiects  going  on  in  the  UK  and  Europe  to  combine  a  proof  sysimn  with  a  formal 
spedficaiioa  notatkn.  Of  most  relevance  is  work  undertaken  tfaroagb  ^PRIT  protects,  for  example  on  the  RAISE 
toolset.  In  terms  of  MALPAS,  we  are  ooutinually  enhancing  the  tool  to  improve  the  effectiveness  of  its  proof  ability 
(induding  the  current  development  of  a  complete  enw  toolset),  but  we  are  not  at  present  working  to  integrate  the  tool 
with  any  particular  fonnal  specification  language. 

Question  R.SZYMANSKI 

Will  your  approach  work  cost-effectively  for  large  programs?  (i.e.  does  the  effon  increase  linearly  or  exponentially  when 
the  code  size  doubles?) 

Reply 

On  this  particular  prpiect,  there  were  significant  ’end  effect’  costs  because  the  system  was  so  small.  As  the  size  of  the 
software  increases,  we  should  expect  initially  to  see  economies  of  scale.  However,  beyond  a  certain  size,  one  would 
teach  a  level  of  conqrlexity  where  the  difficulty  of  producing  a  formal  specification  vouM  start  to  increase  the  costs. 

Question  L.  COGLIANESE 

To  what  degree  did  the  fiict  that  the  program  was  written  in  assembler  hdp  or  hinder  your  efforts? 

Reply 

Overall  the  fact  that  the  code  was  assembler  increased  the  formal  verificatioa  effort  since  one  had  to  refine  the  (high 
level)  Zspecificmion,  written  in  terms  of  system  level  vatiales,  down  to  the  assembler  level  where  one  is  dealing  with 
specific  assendto  commands  (such  as  bit  matching  and  doable  let^  arithmetic).  High  level  languages  would  have 
meant  that  one  does  not  have  to  go  down  to  sudi  a  low  level. 

Oiestioa  W.  ROYfX 

In  a  retrospective  way.  when  applying  formal  methods  to  existing  code,  are  certain  languages  semantics  (i.e.  C,  Ada, 
Fortran,  C]k)bol,  C+*)  better  than  oth^  For  example,  is  Ada  tasking  easy  or  hard  to  v^fy? 

Reply 

Yes,  certain  tanguages  are  better  than  others.  C.  for  example,  is  difficult  because  there  are  few  discii^ining  featiaes.  In 
coaqMriaoa,  Ada  would  be  better.  However.  Ada  tasking  is  very  difficult  and  most  be  excluded. 
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Abstract 

This  p^>er  discusses  the  impact  DOD  de- 
velojunent  standards  and  Integrated  Product 
Teams  have  had  on  influencing  F-22  cockpit 
Controls  and  Displays  software  test  and 
evaluation. 

Integrated  Product  Development  Teams 

Recently,  The  United  States  Air  Force  insti¬ 
tuted  a  new  approach  to  weapon  system 
development  which  employs  Integrated 
Product  Development  Teams  (IPTs).  In  the 
past,  a  system  was  developed  as  a  series  of 
independent  activities  performed  by  differ¬ 
ent  groups  commencing  with  subsystem 
design  and  proceeding  step  by  stq>  to  sys¬ 
tem  deployment.  At  each  step  sdong  the 
way,  new  groups  of  people  b«gan  their  ac¬ 
tivity  where  oAers  left  off.  Communica¬ 
tions  betweoi  groups  was  practically  nil.  If 
the  manufacturing  group  needed  to  under¬ 
stand  a  particular  design  subtlety  they  would 
have  to  seek  out  the  assistance  of  the  prin¬ 
ciple  design  engineer  on  an  ad  hoc  basis 
who  would  then  rely  on  his  own  resources  to 
answer  their  questions.  Whenever  the 
principle  design  mgineer  became  unavail¬ 
able  because  he  was  reassigned  or  otherwise 
changed  employment,  the  manufacturer  was 
forced  to  make  a  best  judgment  and  press 
on.  Test  engineers,  siqiport  equipment  de¬ 
signers  and  logisticians  suffered  similar 
problems.  If  they  needed  help  in  under¬ 
standing  a  particular  design,  they  would 


have  to  seek  out  the  principle  design  en¬ 
gineer  and  hope  he  was  available  to  assist 
them.  Under  the  IPT  concq>t,  major  seg¬ 
ments  of  an  overall  weapon  system  are 
managed  by  a  product  team  poptilated  with 
both  contractor  and  government  personnel 
with  a  wide  range  of  disciplines.  The  IPT 
approach  to  system  development  is  a  paral¬ 
lel  process.  The  team  manages  the  devel¬ 
opment  of  their  product  from  the  design 
phase  dirou^  test,  manufacturing  and  de- 
ploymott.  All  disciplines  including  pro¬ 
gram  management,  financial  management, 
contracts,  data  management,  configuration 
management  and  logistics,  as  well  as  design, 
test  and  manufacturing  engineering  are 
represented  on  the  IPT.  All  parties  become 
involved  with  the  system  early  in  the 
requirements  definition  phase  of  the  pro¬ 
gram  and  participate  in  each  stq>  of  the  de¬ 
cision  making  process  throughout  the  devel¬ 
opment  cycle.  Experience  gained  on  the 
U.S.  Air  Force  F-22  program  provides  the 
basis  for  this  p^>er  which  will  illustrate  how 
the  IPT  concept  has  improved  the  software 
design  and  test  process. 

Background 

The  use  of  software  in  complex  military 
systems  has  grown  rapidly  in  recent  years. 
Expanded  memory  devices,  faster  proces¬ 
sors,  reduced  form  factors,  economical 
power  consumption  and  low  prices  have  ail 
led  to  the  expanded  use  of  microprocessors 
to  implement  system  functions  which  were 
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formerly  implemented  in  electronic  hard-  of  the  particular  software  effort  to  be 

ware  components.  Discrete  resistors,  ca-  developed  the  first  step  in  the  requirements 

pacitors,  operational  amplifiers,  logic  gates  process  is  to  generate  a  Systems  Require- 

and  transistors  have  been  replaced  in  many  ments  Document  (SRD).  This  document 

applications  by  miniaturized,  programmable  defines  overall  system  requirements  in  terms 

clocked  sequential  machines.  The  reason  of  performance  parameters.  In  addition,  the 

for  this  phenomenon  is  simple.  Pro-  SRD  flows  down  pertinent  software 

grammable  devices  are  flexible;  software  is  requirements  called  out  by  the  two  E>OD 

easier  to  change  than  hardware.  Hardware  standards  cited  above  such  as  top-down  de¬ 
change  is  labor  intensive  and  requires  a  sign,  structured  programming,  use  of  higher 

physical  component  replacement.  Software  order  programming  languages,  quality  as- 

can  be  changed  with  a  key  stroke.  An  surance  measures  and  other  specifications 

advantage  of  hardware  is  that  the  design  is  tailored  to  the  application.  Frequently,  the 

visible  through  schematic  and  physical  lay-  initial  version  of  the  SRD  is  written  by  the 

out  drawings.  Changes  can  be  easily  identi-  procuring  agency  with  assistance  from  his 

fied  through  the  drawing  release  system  or  if  customer,  the  user.  It  may  also  be  submitted 

need  be  by  an  actual  equipment  configu-  to  industry  for  review  and  comment.  When 

ration  audit.  Hardware  change  control  is  possible  die  final  version  of  the  SRD  is  dis- 

ridged  and  highly  visible.  On  the  other  cussed  with  potential  contractors  in  an  open 

hand,  software  is  not  visible.  Nothing  about  forum  setting  before  it  is  released  as  part  of 

the  software  is  revealed  by  an  external  ex-  a  Request  For  Proposal  for  system  develop- 

amination  of  the  processor  it  resides  in.  ment. 

Moreover,  the  processor  code  listing  pro¬ 
vides  little  understanding  of  the  design.  As  After  contract  award,  the  SRD  becomes  the 

we  will  see  in  the  following  paragraph,  responsibility  of  the  prime  contractor.  It  is 

many  steps  have  been  taken  to  document  used  by  the  contractor  as  a  basis  to  partition 

softivare  development  in  order  to  provide  the  total  system  into  smaller  segments  or 

design  visibility  and  software  change  con-  subsystems  to  perform  delegated  functions, 

trol.  Each  segment  or  subsystem  is  described  by 

a  Prime  Item  Development  Specification 
Requirements  which  comprises  both  hardware  and  soft¬ 

ware  elements.  Each  distinct  software  ele- 
The  United  States  Department  of  Defense  ment  is  called  a  Computer  Software  Con¬ 
formally  recognized  the  necessity  to  design  figuration  Item  (CSCI)  and  is  defined  by  a 

and  document  Mission  Critical  Computer  requirements  document  which  contains 

Software  (MCCS)  for  use  in  United  States  software  design  requirements  directly  stated 

military  systems  systematically  by  mandat-  by  the  SRD  plus  additional  derived 

ing  that  it  be  developed  in  accordance  with  requirements  which  result  from  system 

Department  Of  Defense  Standards  2167  partitioning  or  from  the  refinement  of  par- 

(DOD-STD-2167)  and  2168  (DOD-STD-  ticular  performance  specifications.  All 

2168).  These  documents  provide  the  stated  requirements  must  be  traceable  to 

ftamework  for  software  design,  develop-  system  performance  requirements  stated  in 

ment,  test,  documentation  and  quality  as-  the  SRD.  The  requirements  document  is  a 

surance.  They  are  sufficiently  flexible  to  "design  to”  specification  which  establishes 

permit  the  tailoring  of  specifications  to  fit  a  CSCI  functional  capabilities,  performance 

variety  of  software  applications.  Regardless  values  and  tolerances,  input/outputs,  se- 
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quencing  ccmtrol,  error  detection  end  re¬ 
covery,  real  time  diagnostics,  operational 
data  recording,  quality  control  provisions, 
operating  limitations  and  other  requirements 
peculiar  to  the  software  application.  The  re¬ 
quirements  specification  establishes  the 
baseline  for  software  design. 

The  actual  software  design  is  documented  in 
a  detailed  q;>ecification  which  describes  the 
CSCI  structure,  functions,  languages,  data 
base  and  smaller  computer  program 
components.  It  also  describes  the  overall 
flow  of  both  data  and  control  signals  within 
the  CSCI,  timing  and  sequencing  of  opera¬ 
tions  and  other  pertinent  information.  After 
the  software  has  been  coded  and  tested  the 
design  specification  describes  the  final  soft¬ 
ware  pr^uct.  The  design  specification  for 
software  is  analogous  to  engineering  draw¬ 
ings  for  hardware. 


Software  design  is  a  top-down  process 
which  results  in  the  synthesis  of  transfer 
functions  and  algorithms  to  be  hosted  in  a 
hierarchy  of  integrated  program  code 
building  blocks  also  evolved  in  the  design 
process.  Top-down  design  facilitates  bot- 
tom-up  software  testing  and  minimizes  de¬ 
sign  changes  by  defining  system  interfaces 
before  detailed  algorithms  are  produced. 
The  five  major  stq>s  in  the  design  process 
are  listed  below; 

1.  Define  software  design  require¬ 
ments. 

2.  Perfcnm  external  system  level 
interface  design. 

3.  Lay  out  the  software  Architec¬ 
ture. 

4.  Perform  module  level  interface 

design. 


S.  Synthesize  module  transfer  func¬ 
tions  and  algorithms. 

The  first  step  in  software  design  is  to  con¬ 
duct  a  software  requirements  analy«s  based 
on  the  Systems  Requirements  Document  and 
generate  the  computer  software  require¬ 
ments  specification.  Where  possible,  re¬ 
quirements  are  stated  in  terms  of  the  CSCI 
input/output  interface  signals  and  transfer 
functions. 

The  second  step  in  the  top-down  design 
process  is  to  address  CSCI  external  inter¬ 
faces.  This  entails  designing  software  rou¬ 
tines  for  devices  which  accept  input  timing, 
control  and  logic  signals  from  sources  out¬ 
side  the  CSCI  and  provide  output  variables 
in  the  form  of  electrical  signals  to  exterior 
destinations.  Typically,  the  input/output 
devices  interface  with  a  data  bus  such  as  Aat 
described  in  Military  Standard  1SS3B.  Ex¬ 
ternal  interface  requirements  are  often  es¬ 
tablished  through  an  interface  control 
working  group.  IPTs  are  accustomed  to 
working  in  ^ups  and  are  very  effective  in 
this  forum.  It  is  important  to  accomplish  the 
external  interface  design  before  proceeding 
further  to  avoid  signal  characteristic 
incompatibilities  and  timing  problems. 

In  step  three,  the  designer  evaluates  how  the 
overall  software  design  can  be  broken  down 
into  smaller  functional  elements.  The  term 
software  architecture  refers  to  the  type  and 
arrangement  of  building  blocks  which  are 
linked  together  to  construct  the  CSCI.  In 
some  cases,  software  architecture  is  a  con¬ 
straint  imposed  on  the  system  design  by 
other  factors  such  standardization.  Barring 
such  a  constraint,  the  product  software  could 
be  implemented  in  one  large  central  proces¬ 
sor  or  it  could  be  distributed  over  several 
smaller  processors.  In  either  case,  the 
designer  partitions  the  CSCI  into  smaller 
elements  called  modules,  components  and 
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units.  The  smallest  elemoit  of  software  is 
the  unit  which  consists  of  about  200  execu¬ 
table  lines  of  software  code.  Partitioning 
simplifies  the  programming  task  and  facili¬ 
tates  tracking  and  documenting  the  software 
design. 

In  step  four,  the  designer  develops  routines 
to  interface  smaller  software  modules  to- 
g^a  to  produce  the  integrated  CSCI  func¬ 
tion.  Particular  attention  is  given  to  module 
connectivity  and  the  timing  and  sequencing 
of  data. 

The  final  step  of  the  design  process  is  to 
synthesize  module  transfer  functions  and  al¬ 
gorithms  and  document  this  product  in  the 
detailed  design  specification.  The  existence 
of  firm  requirements  eliminates  costly 
redesign  which  can  result  from  floating 
interface  specifications. 

Software  Testing 

Software  testing  is  the  process  of  executing 
a  computer  program  with  the  intention  of 
finding  errors.  Historically,  the  individual 
who  designed  a  particular  computer  pro¬ 
gram  or  algorithm  also  coded  the  program 
and  served  as  the  tester  of  the  resultant 
product.  The  problem  with  such  an  ap¬ 
proach  is  that  Ae  designer/tester  tends  to 
delineate  test  procedures  which  verify  that 
the  program  executes  as  coded.  Verifying 
that  code  executes  as  expected  in  the  labo¬ 
ratory  is  quite  different  from  verifying  that  a 
system  satisfies  performance  requirements 
under  operating  conditions.  In  order  to  ac¬ 
complish  the  latter,  software  test  require¬ 
ments  must  be  stated  in  terms  of  system 
performance  requirements  which  can  ulti¬ 
mately  be  verified  b>  test  at  the  system 
level. 

F-22  Controls  .‘'jd  Displays  Test  and 
Evaluation 


£>evelopment  of  the  United  States  Air  Force 
F-22  aircraft  cockpit  Controls  and  Displays 
(C/D)  is  managed  by  an  Integrated  Product 
Team.  The  team  is  concerned  with  every 
phase  of  product  development  and  operation 
from  "ciadle  to  grave"  including  per¬ 
formance,  cost,  schedule,  testability,  pro- 
ducibility,  and  suppoitability.  Team  mem¬ 
bership  is  made  iq>  of  both  contractor  and 
government  personnel  representing  all  disci¬ 
plines  involved  in  the  business  of  systems 
acquisition.  The  F-22  System  Program 
Office  is  committed  to  the  premise  that  re¬ 
quirements  definition  and  soffi^'are  docu¬ 
mentation  are  vital  to  successful  system  de- 
velopmatt.  Experience  has  also  demon¬ 
strated  that  rigorous  testing  is  a  mainstay  in 
assuring  proper  software  design.  With 
these  factors  in  mind,  the  team  approach  to 
software  design  and  test  has  adopted  the 
following  guidelines; 

A.  Start  with  requirements  and  ad¬ 
here  to  established  software  development 
rules. 

B.  Integrate  software  test  into  the 
systems  engineering  process. 

C.  Rigorously  test  software  to  sys¬ 
tem  performance  requirements. 

From  die  foregoing  discussion  on  require¬ 
ments,  it  is  evident  that  adequate  direction  is 
on  the  books  to  insure  that  military  software 
development  is  properly  conducted  and 
documented.  Unfortunately,  in  the  past  it 
has  been  difficult  to  implement  existing  di¬ 
rection.  Prior  to  the  use  of  IPTs,  the  task  of 
wnting  software  design  requirements  was 
left  up  to  the  designer.  Eager  to  get  started, 
the  designer  would  often  times  forego  con¬ 
ducting  and  documenting  a  software  re¬ 
quirements  analysis.  Instead,  he  would  code 
and  test  bits  and  pieces  of  functions  which 
he  thought  he  understood.  He  would  iterate 
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this  procedure  until  he  finally  came  up  with 
some  conglomeration  of  fimctions  that 
seemed  to  work.  The  code  for  this  con¬ 
glomeration  would  then  become  the  soft¬ 
ware  "design".  In  one  notable  case,  a  major 
avionics  system  actually  entered  flight  test 
without  having  either  an  approved  require¬ 
ments  document  or  a  detailed  design  speci¬ 
fication.  The  order  of  the  day  was  to  flight 
test  the  system,  analyze  the  results  and  fix 
anything  that  didn't  work  correctly.  With  no 
documented  requirements,  it  was  nearly 
impossible  to  determine  what  worked  and 
what  didn't.  Needless  to  say,  that  project 
turned  out  to  be  a  disaster  in  terms  of  cost 
overruns  and  generally  poor  system  per¬ 
formance.  The  use  of  I^s  has  alleviated 
this  situation  by  enforcing  standard  software 
development  practices.  IPTs  endeavor  to 
state  software  performance  requirements  in 
clear,  concise,  unambiguous  and  quanti¬ 
tative  language  so  that  all  parties  understand 
what  the  software  is  supposed  to  do  and  why 
it  is  suppose  to  do  it  that  way. 

Probably  the  most  challenging  job  of  the 
detail  designer  is  coping  with  changing  re¬ 
quirements.  IPTs  are  very  useful  in  stabi¬ 
lizing  design  requirements  and  resolving 
conflicts.  It  is  worth  noting  that  require¬ 
ments  sometimes  must  change  for  good  rea¬ 
son.  For  example,  an  integrated  logistics 
support  requirement  might  be  stated  as  fol¬ 
lows;  "The  product  software  shall  provide  a 
post  mission  in-flight  built-in-test  diagnostic 
capability  which  shall  fault  isolate 
equipment  malfunctions  to  the  line  replace¬ 
able  unit  level  prior  to  aircraft  landing." 
The  intent  of  the  requirement  is  to  increase 
sortie  rate  by  eliminating  the  use  of  special 
ground  support  equipment  to  trouble-shoot 
failures  occurring  during  a  mission.  While 
this  requirement  may  be  desirable,  it's  im¬ 
plementation  necessitates  the  addition  of 
special  avionics  built-in-test  equipment 
which  may  unduly  burden  the  system  with 


additional  weight,  power  consumption,  and 
heat  dissipation  demands.  A  cost/beneflts 
trade  analysis  would  be  necessary  to  resolve 
this  issue.  IPTs  have  proven  to  be  particu¬ 
larly  useful  at  evaluating  alternative  solu¬ 
tions  to  such  conflicting  requirements.  In 
this  case  Logisticians  and  Mission  Plannm 
understand  the  operational  need  for  built-in¬ 
test  fault  isolation.  Designers  understand 
the  extent  and  complexity  of  the  hardware 
and  software  needed  to  implement  the 
required  cqiability  and  the  time  required  to 
accomplish  the  ta^.  Program  management 
understands  budgetary  limitations  and 
schedule  constraints.  Considering  all 

elements  of  the  problem;  performance,  cost 
and  schedule,  the  IPT  is  eminently  qualified 
to  decide  the  fate  of  the  stated  requirement. 

In  the  case  of  the  F-22  Controls  and  Dis¬ 
plays,  software  development  is  being  exe¬ 
cuted  in  strict  compliance  with  DOD  stan¬ 
dards.  Software  design  did  not  begin  until 
after  the  Software  Requirements  Specifica¬ 
tion  (SRS)  and  the  Interface  Requirements 
specification  (IRS)  were  approv^  at  pre¬ 
liminary  design  review.  Coding  of  the  de¬ 
sign  will  not  begin  until  after  the  Software 
Detail  Design  Document  (SDDD)  and  the 
Interface  Description  Document  (IDD)  re¬ 
ceive  approval  at  critical  design  review. 

Furthermore,  software  test  has  been  an  in¬ 
tegral  part  of  the  systems  engineering  proc¬ 
ess  from  day  one.  Test  planning  was  initi¬ 
ated  in  parallel  with  software  requirements 
definition.  Each  requirement  in  the  software 
requirements  specification  is  identified  by 
number  in  a  separate  paragraph.  Numbering 
enables  a  requirement  to  be  traced  to  the 
Software  Detail  Design  Document  and  to 
the  Test  Verification  Matrix.  It  also  con¬ 
trols  the  addition  of  extraneous  requirements 
not  derived  from  the  original  SRD  and 
eliminates  what  has  been  called  "creeping 
elegance". 
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The  IPT  test  engineer  is  responsible  for 
knowing  how  the  total  system  is  supposed  to 
perform  at  the  operational  level.  He  par¬ 
ticipated  in  translating  operational  character¬ 
istics  into  stated  software  performance  re¬ 
quirements.  Once  overall  requirements 
were  defined,  the  C/D  IPT  test  engineer 
helped  generate  a  comprehensive  system 
Test  and  Evaluation  Master  Plan  (TEMP). 
The  TEMP  identifies  the  entire  test  process 
from  the  checkout  of  individual  components 
to  modules  to  subsystems  to  system  seg¬ 
ments  and  finally  to  the  integrated  system. 

Using  the  TEMP  as  a  guide,  the  test  engi¬ 
neer  formulated  detailed  test  procedures  for 
the  C/D  product  in  parallel  with  the  design 
process.  He  concentrated  on  developing  test 
requirements  and  test  cases  which  are 
directly  traceable  to  system  performance 
requirements.  Software  test  cases  were  es¬ 
tablished  without  regard  to  code.  The  fol¬ 
lowing  is  an  example  of  test  requirements 
stated  in  terms  of  quantifiable  software  in¬ 
put/output  parameters  and  the  CSCI  transfer 
function: 

(1)  The  nose  index  Uncage  Conunand  (UC) 
output  signal  shall  be  set  to  S.Ovdc  plus  or 
minus  l.Ovdc  when  BOTH  of  the  following 
input  conditions  are  present; 

A.  Lock-On  signal  (LO)  equals 
S.Ovdc  plus  or  minus  l.Ovdc 

B.  System  Ready  signal  (SR)  equals 
S.Ovdc  plus  or  minus  l.Ovdc 

(2)  If  either  the  Lock-On  signal  or  the  Sys¬ 
tem  Ready  signal  is  O.Ovdc  plus  or  minus 
l.Ovdc,  then  the  Uncage  Command  output 
shall  be  set  to  O.Ovdc  plus  or  minus  1  .Ovdc. 

In  this  example,  two  requirements  have  been 
stated.  First,  the  logic  transfer  function  of 
the  software  unit  is  specified  to  be: 


UC=LO  AND  SR 

Secondly,  interface  signal  logic  levels  are 
defined: 

Logical  one  equals  S.Ovdc 
plus  or  minus  1  .Ovdc 

Logical  zero  equals  l.Ovdc 
plus  or  minus  1  .Ovdc 

The  requirements  stated  above  represent 
functions  which  are  "testable"  independent 
of  the  code  used  to  implement  the  software. 
The  following  are  examples  of  requirements 
which  do  not  relate  to  system  performance 
and  which  are  therefore  not  "testable”. 

1.  The  Software  shall  generate  the  nose  in¬ 
dex  marker  as  necessary. 

2.  The  Software  shall  satisfy  all  system 
constraints. 

3.  The  Software  shall  be  sufficient  to  sup¬ 
port  mission  planning. 

4.  The  Software  shall  self  test  the  processor 

The  IPT  test  engineer  also  writes  the  Test 
Description  Documents  and  the  Test  Proce¬ 
dure  Documents  which  are  used  to  execute 
software  Preliminary  Qualification  Testing 
(PQT),  Formal  Qualification  Testing  (FQT) 
and  Acceptance  Testing  (AT).  Software 
testing  is  performed  in  a  "bottoms-up"  man¬ 
ner  at  the  unit,  component  and  module  level. 
PQT  is  the  most  stringent  and  stressful  type 
of  testing  that  is  performed  to  assure  that  the 
software  satisfies  transfer  function  design 
requirements.  PQT  verifies  that  all  legiti¬ 
mate  combinations  of  operational  input  sig¬ 
nals  to  a  particular  software  element  pro¬ 
duce  the  expected  outputs  signals.  It  also 
verifies  that  other  input  signal  combinations 
which  are  not  expected  to  occur  during 
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normal  operations  do  not  cause  the  software 
to  "lock-up"  or  cause  tqpurious  outputs  or 
other  "glitches".  PQT  also  int^uces 
boundary  value  conditions  which  exercise 
the  software  tolerance  limits  under  worst 
case  conditions  in  an  effort  to  produce 
faults.  FQT  is  conducted  at  the  CSCI  level 
and  verifies  that  implication  of  the  proper 
input  signals  to  a  CSCI  produce  the  proper 
output  signals.  Acceptance  testing  is  not  a 
software  design  verification  test.  It  is  a 
functional  test  which  demonstrates  that 
hardware  and  software  are  operating  to 
nominal  poformance  levels.  IPTs 
strengthen  the  software  test  and  evaluation 
process  because  test  is  treated  as  an  inde¬ 
pendent  discipline  which  begins  with  the 
origination  of  system  performance  require¬ 
ments  rather  than  as  a  follow-on  effort  to 
software  design. 

Conclusions 

Existing  DOD  standards  are  in  place  which 
adequately  describe  a  viable  software  de¬ 
velopment  process.  Implementation  of  these 
standards  coupled  with  a  rigorous  test 
methodology  will  result  in  high  perform¬ 
ance,  cost  effective  software. 

Integrated  Product  Teams  facilitate  com¬ 
munications,  serve  as  corporate  memory  and 
provide  continuity  to  the  system  develop¬ 
ment  process.  IPTs  provide  the  manage¬ 
ment  muscle  necessary  to  enforce  existing 
DOD  software  development  standards  and 
produce  a  quality  product. 
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Discussion 


Question  L.  HOEBEL 

Could  you  describe  the  10%  of  F-22  software  that  is  not  in  Ada?  What  language,  what  functionality  and  why  not  Ada? 
Reply 

9%  is  in  assembly.  The  assembly  is  done  at  Hughes  Aircraft  It  is  needed  because  of  ibe  liming  of  the  chip  in  our  Central 
Inteifce  Processor  (CIP). 

1%  is  in  C  because  it  is  more  cost  effect  to  use  tbe  language  in  off-the-shelf  equipment  than  to  rewrite  in  Ada. 
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1.  SUMMARY 

A  new  approach  is  presented  to  the  through-life 
support  and  evolution  of  software-intensive  systems, 
inv^ving  a  sequence  of  development  contractors.  The 
problems  addressed  are  to  do  with  the  avoidance  of  a 
“through-life  dependency”  on  any  of  the  development 
contractors,  and  of  achieving  a  unified  engineering 
system  description  without  imposing  undue  restrictions 
on  the  use  of  evolving  software  methodologies. 

The  UNICON  approach  is  to  vest  the  through-life 
continuity  in  a  unified  engineering  description  held  in  a 
new  type  of  Project  Support  Database.  This  scheme 
now  views  the  development  contractors  as  having  a 
“Jobbing”  role. 

The  technical  feasibility  of  this  approach  was  held  to 
depend  on  achieving  a  mu<^  more  complete 
engineering  description  -  from  the  Statement  of 
Requirement,  through  to  the  mapping  of  the  software 
onto  the  hardware  (variants)  -  than  any  yet  available. 
This  led  to  the  development  of  the  UNICON  system 
description  language,  based  on  extensions  to  the 
familiar  ENTlTY/RELAnON/ATTRlBUTE  notation. 

Details  are  presented  of  a  reverse  engineering 
experiment  which  captured  a  description  of  an  existing 
27-processor  equipment  within  a  prototype  UNICON 
database.  This  also  involved  codifying  the  software 
production  processes,  the  results  being  verified  by 
replicating  an  existing  software  build,  purely  from  the 
UNICON  information.  An  outline  is  given  of  the 
UNICON  Project  Support  Environment. 

A  new  approach  is  proposed  to  the  standardisation  of 
Software  Suppon  Environments,  whose  objective  is  to 
support  the  transfer  of  work  between  conforming 
Environments,  rather  than  to  unify  their 
implementations.  This  idea  is  contrasted  with  the  more 
familiar  Public  Tool  Interface  standardisation  scheme. 

2  INTRODUCTION 

Over  the  past  five  years  the  UNICON  research 
programme  has  produced  a  new  approach  to  the 
through-life  support  of  large  software  intensive 
systems.  With  the  latest  trends  towards  system 
integration,  there  is  an  increasing  awareness  by 
lYojects  of  the  need  to  avoid  a  through-Ufe- 
dependency  on  any  one  development  contractor.  Thus 
on-going  system  evolution,  perhaps  over  a  thirty  year 

Views  expressed  are  those  of  the  author 


span,  may  have  to  involve  a  sequettce  of  development 
contractors  -  each  operating  on  a  “jobbing”  basis. 

For  such  an  approach  to  be  feasible,  it  would  require  a 
standard  of  Engineering  Documentation  well  beyond 
anything  yet  demonstrated,  since  system  design- 
continuity  would  now  have  to  be  supplied  by  this 
documentation.  Furthermore  a  unified  engineering 
notation  would  be  needed  for  the  entire  system, 
capable  of  describing  different  design  methodologies, 
and  of  evtdving  to  encompass  future  advances. 

Although  aimed  initially  at  capturing  a  unified 
description  of  the  work  done  by  many  development 
contractors,  perhaps  through  a  process  akin  to 
“reverse-engineering",  it  can  readily  be  appreciated 
that  such  an  engineering  notation  could  aiso  be  used  to 
co-ordinate  the  development  work  itself.  From  this  it 
follows  that  a  UNICON  Software  Environment  is 
equally  applicable  to  both  system  support  and  to 
software  development.  (In  fact  UNICON  has  been 
specifically  designed  to  co-ordinate  very  large 
development  teams  -  perhaps  one  thousand  engineers 
or  more). 

Finally  the  notion  of  basing  a  new  standard  for 
Software  Support  Environments  on  an  Engineering 
Description  Notation  is  contrasted  with  the  present 
Public  Tools  Interface  (PTI)  approach  -  as  in  the  PCTE 
programme  etc.  The  question  is  raised  as  to  whether 
the  capability  of  transferring  development  work 
between  conforming  Environments,  is  a  much  more 
direct  standardisation  objective  than  some  capability  to 
implement  individual  Environments  from  standardised 
tool-components. 

3  THE  UNICON  APPROACH 

3.1  Fig  1  The  Through-life  Support  Problem 

Current  practice  is  for  a  new  software  issue  to  be  made 
up  from  separate  components,  each  compiled  by  the 
original  Development  Contractor. 

Elaborate  interface  specifications  are  used  to 

co-ordinate  the  software  builds  from  different 

Contractors. 

This  leads  to  a  through-life  dependency  on  the  original 
development  contractors. 


Presented  at  an  AGARD  Meeting  on  Aerospace  Software  Engineering  for  Advanced  Systems  Architectures’,  May  1993. 
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Osvsiopmsnt  Contractors 
*How  do  you  go  about  new  Counter 
measures  Function? 

Fig  I 


Perhaps  fifty  years  in  some  cases. 

How  do  we  cope  with  an  evolutionary  requirement 
which  spans  a  number  of  development  areas  ? 

Such  difficulties  will  eventually  be  the  limiting 
factor  in  upgrading  existing  systems. 

These  problems  will  become  more  acute  with 
the  moves  towards  integrated  systems. 

3.2  Fig  2  The  Unicon  Solution  To  Through>life 
Support 

Now  Approach  To  Through  Life 
Software  &  Design  Management 


*No  through-life  dependency  on  any 
Contractor 

‘Uniform  &  '‘Seamless'*  description  held  for 
entire  system 

-  Updates  eg;  Countermeasures  Fn  specified  using 
UNICOM  lirformation. 

Fig  2 

The  UNICON  database  captures  a  description  of  each 
Development  Contractor's  work,  to  form  a  unified 
"seamless"  system  description. 

This  may  involve  “reverse-engineering"  each 
Contractor's  documentation. 


UNICON  ^ «««*»««>  -  probably  by  a  Systems-Suppoit 
Contractor. 

—  There  is  no  dependeiwy  on  any  of  the 
Development  contractors. 

—  Thus  the  UNICON  systems  description  must 
include  a  codification  of  the  software 
production  processes  (ie  compiling,  linking 
etc). 

Requirements  for  evolutionary  enhancements,  are  now 
specified  in  terms  of  the  database  system  description. 

The  Systems-Support  Contractor  is  involved  in 
elaboi^ing  this  requirement  -  and  eventually  in 
overseeing  the  upgrade  of  the  database.  They 
would  have  to  certify  that  they  can  now  support 
the  new  function,  before  the  development 
contractor  can  be  paid  off. 

3J  Fig  3  Unicon  Describes  Systems  Using  An 
Extended  ENTITY/RELATION  Model 
System  description  in  UNICON  is  based  on  an 
extension  of  the  familiar  ENTITY/RELATION 
notation.  Fig  3  shows  that  a  UNICON  ENTITY  is  just 
an  Identifier,  which  can  enclose  a  nested  set  of  child 
ENTITIES  (ie  child-identifiers). 

UNICON  ENTITY  Identifiers  are  in  fact  unique 
database  reference  numbers  (rather  like  “path" 
names).  A  User  Name  for  an  ENTITY  is 
optional,  and  is  treated  as  an  alias. 

RELATIONS  express  "links"  between  ENTITIES. 
Sets  of  RELATIONS  are  held  in  parallel  planes  - 
rather  like  a  multilayer  electronic  circuit  board,  where 
the  ENTITIES  correspond  to  the  microchips,  and  the 
sets  of  RELATIONS  correspond  to  the  separate  layers 
of  inter-connections. 

Separate  planes  of  RELATIONS  express 
separate  classes  of  “links"  ~  eg  links  which 
describe  connections  between  code-module 
EN  ITriES.  arc  of  a  different  class  to  those  links 
which  assign  code  modules  to  processor 
address-spaces. 

The  bulk  of  the  information  within  a  UNICON 
daubase  is  held  as  “anonymous"  ATTRIBUTES, 
which  are  bound  to  individual  ENTITIES. 

It  is  rather  like  each  ENTITY/  RELATION 
providing  extensive  management  and  version- 
control  facilities  for  a  "safe-deposit”  box, 
without  taking  any  interest  in  the  contents  held 
within  each  box  -  other  than  the  specification  of 
the  links  to  other  boxes. 

3.4  Fig  4  A  Typical  Unicon  Project  Support 
Database 

Fig  4  shows  that  a  typical  UNICON  database  is 
configured  rather  like  a  three-dimensional  stack  of 
bricks. 


Each  “brick"  is  itself  made  up  of  numerous 
ENTITY/RELA'nON  planes. 


( 


f) 


( 


4r 


9 


( 


Complete  software  issues  are  now  generated  from  the 
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The  Database  x-axis  holds  parallel  sets  of  hierarchies. 
These  hierarchies  model  the  system  documentation  • 
from  the  Statement-of-Requirement.  through  to  the 
mapping  of  the  software  modules  onto  the  processor 
hardware,  and  then  on  to  the  hardware  installation 
diagrams  etc. 


variant  can  be  generated  as  required,  by  operating  on 
the  base  design. 

Apart  from  being  more  efTicieni  in  storage,  this 
supports  direct  comparisons  between  platform 
variants. 


-  There  exists  a  one-to-one  conespondence 
between  the  daubase  ENTITIES  and  those  of 
the  system  documentation  -  thus  the  UNICON 
database  has  an  object-orientated  configuration. 

Since  UNICON  constructs  an 
ENTTTY/RELATION  schema-model  of  the 
engineering  documentation,  it  preserves  the 
locality  properties  of  the  system  information  - 
thus  very  large  systems  need  not  incur 
significant  access-time  overheads,  even  with 
modest  PC  workstations. 

The  Database  y-axis  holds  system  design-variants  - 
one  for  each  platform.  Each  variant  is  held  in  the  form 
of  an  incremental  “overlay”  operator,  so  that  any  one 


The  Database  z-axis  shows  the  sequence  of  software 
issues,  for  the  base-design  and  for  all  of  the  platform 
variants. 

As  with  platform  variants,  UNICON  constructs  each 
version  “on-demand”,  from  a  flat  library  of  coitunon 
modules  •  thus  the  same  library  modules  can  be  re¬ 
used  for  the  construction  of  many  versions. 
Similarities/differences  between  versions  can  readily 
be  found. 

A  key  design  concept  is  that  UNICON  holds 
information  in  one  place  only  -  all  other  uses  are 
provided  by  references 

Thus  processor  memory  defmitions  held  in  the 


•  • 


UNICON  DATABASE  MODELS  WEAPONS  SYSTEM  STRUCTURE 


Fig4 
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haniwai*  inveaMxy.  togedier  with  its  ihelf 
localioa  and  cmtnintian-bncItpUmc 
infonnatioa,  aie  an  integral  part  of  the  code- 
ffioflniioii  proom. 

3J  Fig  5  Unkon  Databaw  Has  A  Graphical 
Uacr*iBtcrfnoa 

UNICXDN  has  a  WINDOWS  type  graphical  User 
Interface  -  rather  like  a  simple  Computer  Aided 
Drawing  utility,  as  in  Fig  3. 

However  in  “drawing”  Fig  S,  the  actual  process 
(transparent  to  the  User)  was  to  declare  an 
ENTITY/RELATION  network  to  the  database, 
and  then  to  have  the  database  display  its 
contents  using  a  particular  set  of  IC^N 
Representations. 

UNICON  has  an  extensive  set  of  Navigation  and  Trace 
facilities  to  support  User  database  queries  via  the 
screen. 

These  are  to  be  supplemented  by  a  small  library 
of  navigational  functions  written  in  C,  which 
may  well  allow  SQL-type  query  interfaces  to  be 
constructed  if  required. 

The  present  UNICON  implementation  employs  an 
event-driven  configuration  which  is  compatible  with 
virtually  all  of  the  present  graphics  standards  -  eg 
W1NDOWS3.  X-WINDOWS,  etc. 

Since  graphical  representations  are  held  in 
absolute  co-ordinates  within  the  database  - 
using  the  same  grid  as  POSTSCRIPT  -  simple 


haodlers  can  therefore  mqr  UNICON  piciuns 
to  any  acraen  teaoluhna. 

3A  Fig  d  MuUiila  gapraaMrtarini  Provide 
AHaroadva  Pfbaaa  Viewa 

Fig  6  shows  how  UNICON  can  form  a  new  View  into 
the  daubaae.  by  elaborating  sub-systons  to  any  depth, 
starting  from  any  chosen  diagram. 

This  operation  involves  a  non-linear 
transformation,  since  the  amount  of  “space”  on 
the  new  composite  diagram,  claimed  by  uiy 
one  sub-system,  depends  on  the  content  and 
nested  elaborations  ^  that  sub-system. 

-  The  transformation  to  form  the  new  composite 
View  is  automatic  -  although  the  User  may  wish 
to  pretty  up  the  new  lay-out,  the  information 
wiU  always  be  accurate. 

This  new  composite  View  can  be  used  for  database 
interaction  -  eg  for  system  design  -  there  being  no 
functional  distinction  between  single  and  composite 
Views 

-  Alterations  on  one  View  will  of  course  change 
the  other  Views,  since  they  are  all  generated 
from  the  same  underlying  data  -  this  may 
require  some  prettying-up  of  associated 
(off-screen)  Views. 

Any  number  of  composite  Views  can  be  held  as 
parallel  Representations  bound  to  the  ENTITY  frame 
describing  any  one  diagram. 
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—  An  existing  composite  View  can  also  be  used  as 
a  component  within  a  superior  composite  View. 

—  In  this  way  it  would  be  possible  to  perform  a 
bonom-up  construction  of  a  single  composite 
View  for  an  enormous  system  -  and  print  it  out 
as  POSTSCRIPT  tiles  to  cover  the  wall. 

The  composite  View  facility  provides  an  answer  to  the 
so-called  “white  space  pr^lem”  -  where  individual 
diagrams  in  a  hierarchy  do  not  show  enough  context 
information,  ie  each  diagram  is  surrounded  by  a  sea  of 
white  space. 


-  ADA  Bhur  diagrams  are  panirailarly  praoe  to 
tius  oottditiow. 

3.7  Hg  7  IlhtraUm  itow  IMcoa 

OoctMMBtalioa  b  Aa  Imgral  Purt  Of  The 
Code  CoMtnictiM  ri  nnai 
Fig  7  provides  a  somewhat  loose  illustialioa  of  how 
the  UNICON  ENTITY/RELATION  notation 
guarantees  the  accuracy  of  the  design  documentatian, 
by  making  each  diagram  an  integral  part  of  the  code- 
construction  process. 

-  As  shown,  the  RELATIONS  between  the  top- 
level  sub-systems  can  be  regarded  as  “ducts” 
which  will  subsequently  carry  inferior 
RELATIONS  generated  by  lower-level  sub¬ 
systems,  and  eventually  by  code  modules. 

-  The  whole  process  is  analogous  to  tunning 
“wires"  b^een  code  modules,  within  a 
system  of  conduits  provided  by  the  superior 
sub-system  links. 

~  Note  that  an  interface  can  be  inspected  by 
opening  a  “duct”  and  tracing  the  “wires”  -  in 
effect  a  new  type  of  database  query  facility. 

Thus  it  is  seen  that  UNICON  supports  a  process  of  top- 
down  design,  foilowed  by  bottont-up  elaboration. 

It  is  possible  to  regard  the  UNICON  ENTITY 
/RELATION  notation  as  a  meta-language  which  sits 
above  conventional  languages  such  as  ADA  etc.  In  faa 
UNICON  provides  a  transformation,  closely  analogous 
to  a  conventional  compiling  process,  in  which  a 
hierarchy  of  sub-systems  is  transformed  to  become  a 
very  kurge  “flat”  network  containing  only  code 
modules  -  which  can  now  be  fed  to  one  or  more 
compilers. 
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-  h  it  Boied  that  such  facilitiet  provide  new 
optioiit  lo  die  tyatem  designer  -  it  is  now  open 
10  chooae  between  having  x  code  modules  at 
suh^stem  level  k,  or  having  100*x  simpler 
code  modules  at  the  lower  level  of  n  say. 
without  in  any  way  reducing  the  degree  of 
checking  done  by  the  compilation  process(es). 
(Ref  2  gives  a  good  treatment  of  the 
continuing  need  for  a  sub-system  construct  to 
supplement  ADA). 

It  is  evident  that  the  above  “compiling”  transformation 
involves  all  of  the  diagrams  in  the  hierarchy  as  an 
integral  pan  of  the  code-generation  process  -  thus 
guaranteeing  the  consistency  of  all  levels  of  the 
documentation. 

If  say  the  top-level  diagram  were  to  be  deleted 
from  the  database,  UNICON  would  not  be  able 
to  trace  connection  paths  whose  threads  passed 
through  the  deleted  RELATIONS. 

Continuing  with  the  meta-language  interpretation,  it 
would  in  fact  be  possible  to  express  the 
ENTITY/RELATION  description  of  the  sub-system 
levels,  as  an  explicit  ASCII  “source  text".  The 
UNICON  transformation  would  now  become  a  true 
symbolic  compiling  operation,  yielding  a  large 
network  of  conventional  (multi-lingual  ?)  source  text 
modules,  suitable  for  feeding  into  conventional 
compiler(s). 

Such  a  symbolic  approach  would  probably 
require  the  equivalent  of  the  UNICON  database 
surrogate  Identifier  reference  system,  in  order  to 
manage  the  large  global  name-space,  used  to 
express  the  connectivity  of  the  resulting 
network  within  the  source  texts. 

Finally,  it  is  put  forward  as  a  conjecture,  that  the  above 
sub-system  “compiling”  transformation  may  be  an 
enabling  technology  to  support  a  new  approach  to 
software-proving,  where  the  above  reduction  process 
would  be  continued  down  to  arrive  at  sufficiently 
simple  code  modules,  that  they  could  be  regarded  as 
true  in  them.'^elves. 

3.8  Fig  8  The  Unicon  Reverse-engineering 
Experiment 

A  Reverse  Engineering  experiment  was  undertaken, 
both  to  develop  and  to  demonstrate  the  UNICON 
concepts.  The  aim  was  to  capture  a  engineering 
description  of  an  existing  in-service  equipment,  within 
a  UNICON  database. 

The  equipment  chosen  has  27  processors 
configured  on  1 2  buses  -  it  was  programmed  in 
CORAUMASCOT. 

However,  the  actual  experiment  was  undertaken 
on  a  pilot  scale  -  a  single  shelf  having  3 
processors  on  one  bus. 

As  shown  in  Fig  8,  the  MASCOT  design  diagrams 
were  transferred  into  the  experimental  UNICON 
Environment  by  drawing  same  on  the  screen. 
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The  aim  was  to  prove  the  accuracy  of  the  UNICON 
engineering  description,  by  replicating  an  existing 
software  issue  -  purely  from  the  information  held 
within  the  database,  together  with  the  original 
compilers  etc 

Thus  it  is  noted  that  the  reverse  engineering  task 
also  involved  codifying  the  proprietary  software 
production  processes,  used  in-house  by  the 
original  contractor. 

3.9  Fig  9  Experiment  Used  Code-generating 
Handlers 

Fig  9  shows  the  overall  scheme.  The  original  software 
production  was  done  using  a  sequence  of  compiling, 
composing,  linking,  etc  utilities  on  a  VAX  mainframe. 
These  operations  were  directed  by  a  set  of  hand-written 
Batch  Command  files. 

Thus  the.  reverse-engineering  task  reduced  to 
one  of  producing  automatically  an  identical  set 
of  Batch  Command  files  -  using  only  the 
information  present  within  the  UNICON 
database. 

The  job  was  done  in  two  parts.  The  UNICON  database 
generates  a  separate  ASCII  Form  file  for  each  code 
module,  which  contains  all  of  the  information  known 
about  that  module  -  the  location  of  the  source-text  files, 
its  connections  to  other  module  Forms,  its  processor 
memory  location,  etc  etc. 

The  original  contractor  produced  an  application- 
specific  handler,  which  read  these  ASCII  Forms,  and 
transformed  the  information  into  the  required  Batch 
Command  file  format 

In  effect,  the  handler  aped  the  manual  work  of 
the  wiginal  designers  -  only  this  time  the 
database  information  which  produced  the 
design  diagrams,  was  an  integral  part  of  the 
code-production  process  -  thus  ensuring  the 
accuracy  of  the  documentation. 

It  should  come  as  no  surprise  that  a  significant  amount 
of  the  reverse  engineering  effort  was  devoted  to 
achieving  a  consistent  set  of  diagrams  -  since  this  was 
the  first  time  that  any  method  was  available  for 
proving  the  original  documentation. 
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Fig  9 


There  is  no  implied  criticism  made  here  of  the 
contracts  -  the  situation  is  held  to  be  an 
inevitable  consequence  of  having  to  rely  on 
manual  checking  procedures. 

This  result  also  provides  strong  evidence  for  the 
existence  of  sutetantial  hidden  costs  involved  in 
updating  equipments,  due  to  in-accurate 
documentation  -  even  when  used  by  the  original 
development  team. 

At  the  conclusion  of  the  experiment,  the  original 
Design  Team  agreed  that  the  scheme  could  readily  be 
scaled  up  to  describe  the  whole  equipment,  and  that 
techniques  used  were  not  specific  to  that  particular  job. 

However,  it  has  also  to  be  recognised  that  only 
a  minority  sub-set  of  the  UNICON  concepts 
were  exercised  during  this  experiment. 

3.10  Fig  10  Outline  Of  The  Present  Unicon 
Implementation 

Fig  10  shows  how  the  present  UNICON 
implementation  is  structured  as  a  Transaction 
Processor,  a  Database  Manager,  a  Representation 
Manager,  a  View  Manager  and  a  User  Interface 
Manager. 

Database  ENTITY/RELATION  diagrams  are  drawn  on 
the  screen  by  passing  object-streams  to  the 
Representation  Manager,  which  expresses  same  in 
terms  of  graphics  strokes  read  from  the  application- 
specific  ICON  store. 

A  Windows-type  User  Interface  is  provided, 
employing  an  event-driven  configuration  which  is 
compatible  with  the  main  graphics  standards  - 
WINDOWS3.  X-WINDOWS  etc. 

The  transformation  from  absolute 
(POSTSCRIPT  compatible)  co-ordinates  to 
pixel  co-ordinates  takes  place  within  the  User 
Interface  -  thus  ensuring  the  portability  of  the 
database  Representations. 

The  View  Manager  allows  the  u.ser  to  look 
simultaneously  at  a  number  of  pictures  in  separate 


WINDOWS.  However  the  rest  of  the  Environment  is 
‘'aware"  only  of  the  single  active  picture. 

The  present  implementation  provides  a  good  real-time 
performance  on  a  386  PC.  and  has  some  3()k  lines  of 
TURBO  PASCAL  code.  A  fully  featured  UNICON 
Environment  is  expected  to  occupy  about  50k  lines  of 
code. 


The  very  small  code  size  reflects  the  simplicity 
of  the  underlying  EN'l  1 1  Y/RELATION 
notation,  and  the  use  of  a  small  set  of  tightly- 
coupled  generic  tools  (eg  the  one  tree- 
diagramming  utility  is  used  to  manage  the  sub¬ 
system.  the  versions,  the  database  segment, 
and  the  User-defined  schema  hierarchies). 

The  portability  between  UNICON 
implementations,  of  the  large  set  of  loosely- 
coupled  (high-value)  tools  -  eg  compilers, 
word  processors,  code-analysers,  project- 
management  tools  etc  -  is  achieved  through 
the  use  of  simple  Handlers,  many  of  them  being 
application  specific. 
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4.  CONFORMANCE  SFECIFICATION  FOR 
A  UNICON  STANDARD 

It  is  prafNxed  Chat  the  only  oonfonnance  nquiiement 
for  any  UNICON  Enviiamnent,  wouU  be  the 
caiMibility  to  import  work  expressed  in  the  UNICON 
ASCII  Transfer  Format  -  and  the  capability  to  le- 
expon  same  (presumably  after  enhancement)  using  the 
same  Format. 

~  In  particular  the  proposed  UNICON  Standard 

does  not  seek  to  specify  the  facilities  provided 
by  any  one  UNICON  implementation  -  although 
the  ability  to  generate  the  UNICON  Format 
does  im|dy  the  use  of  a  small  number  of 
standard  transformation  algorithms. 

Hence  the  actual  facilities  present  within  any 
one  UNICON  implementation  will  be  a  matter 
for  negotiation  tetween  the  User  and  the 
Supplier. 

Since  the  Transfer  Format  consists  of  a  relatively  small 
number  of  ASCII  stream  types,  each  with  a  tight 
specification,  it  follows  that  there  need  be  no 
restriction  on  how  any  conforming  UNICON 
Environment  is  implemented  •  eg  PASCAL  on  a  PC, 
ADA  on  a  SUN/VAX  etc,  etc. 

Because  the  Transfer  Format  consists  of  ASCII  record 
structure  images,  it  follows  that  it  is  possible  to 
import/export  application  information  in  the  form  of 
“anonymous"  database  records.  Thus  the  UNICON 
Import/Export  operations  are  at  the  level  of  trees  of 
design-Versions,  rather  than  at  the  ENTITY/ 
RELATION  notation  level. 

The  situation  is  somewhat  akin  to  doing 
anonymous  sector-by-sector  disk-transfers, 
rather  than  reading  and  transmitting  individual 
files. 

A  particularly  attractive  feature  of  this  Transfer  Format 
approach  to  conformance,  is  that  individual 
Groups/Users  can  be  allowed  a  considerable  freedom 
to  tailor  their  own  Environments,  without  having  to 
worry  about  issues  of  re-validation. 

In  effect,  UNICON  conformance  testing  is  done 
"on-line",  at  each  Transfer  operation  between 
UNICON  Environments. 

In  practice  such  tailoring  would  probably  be 
confined  to  the  provision  of  alternative  tools,  so 
that  the  object  -  encapsulation  properties  of  the 
Database  Manager  would  also  exert  a  powerful 
conformance-preserving  influence. 

5.  SUPPORT  FOR  VERY  LARGE 
DEVELOPMENT  TEAMS 

UNICON  seeks  to  support  large  development  teams 
through  the  database  teing  structured  as  a  tree  of 
independently  managed  SEGMENTS. 

Since  any  ENTITY/RELATION  tree  within  a 
SEGMENT  has  a  parent  ENTITY  within  its 
superior  SEGMENT,  it  follows  that  the 


amagemem  is  fimctinnally  a)uivalaii  to  a 
iiiigle  "seamless"  ENl'iTY/RELATION  uee- 
muctuie  wuhin  a  single  SEGMENT. 

A  SEGMENT  has  its  own  autonomous  Version 
Manager,  which  describes  a  tree  of  Versions  within  the 
SEGMENT. 

-  Each  Version  in  this  tree  records  a  "state”  for 
the  entire  SEGMENT  as  a  whole.  A  state  is 
geiterated  by  an  iterative  indexing  operation, 
which  operates  upon  a  flat  library  of 
ENTTTY/RELATION  objects,  and  on  the 
nested  ATTRIBUTE  Libraries.  Most  library 
objects  are  common  to  many  versions. 

A  SEGMENT  also  has  a  separate  Configuration 
Version  Manager,  whose  function  is  to  select  both  a 
particular  Version  Number  for  the  current  SEGMENT, 
and  to  specify  the  configuration  of  the  child 
SEGMENTS  -  and  their  respective  Configuration 
Version  Numbers. 

In  this  way  every  Version  Number  in  the 
Configuration  tree,  specifies  both  a 
configuration  and  a  state  for  the  present  and  all 
inferior  SEGMENTS.  (Thus  each  Configuration 
version  can  be  regarded  as  a  particular  “view” 
of  some  part  of  the  database). 

in  the  case  of  the  top  SEGMENT,  a 
configuration  and  a  state  for  the  entire  database 
is  specified  for  each  Configuration  Version 
Number  -  essentially  through  a  cascade  of  index 
objects,  distributed  over  the  child 
SEGMENTS. 

The  separation  of  the  SEGMENT  and  the 
Configuration  Version-Managers,  means  that  changes 
within  any  SEGMENT  can  be  done  in  isolation  from 
the  rest  of  the  database. 

In  general  there  can  be  many  (inconsistent  ?) 
SEGMENT-versions  interpolated  between  those 
which  are  made  visible  to  the  test  of  the 
database,  through  being  called  up  as  part  of 
some  new  Configuration-Version. 

A  Section  Leader  can  specify  work-packages  in  the 
form  of  a  particular  configuration  of  SEGMENTS, 
which  can  be  regarded  as  an  independent  and 
consistent  sub-Environment 

This  could  be  implemented  within  a 
mainframe/network  system  as  a  side-branch  of  a 
Version-tree,  or  be  exported  to  a  stand-alone 
PC/SUN  workstation  using  the  ASCII  Format, 
to  start  a  new  Version-tree  -  their  being  no 
functional  distinction  between  local  and 
remotely  sited  sub-environments. 

Library  objects  are  never  changed  in-situ  - 
changed  objects  are  held  in  working  store,  and 
become  new  library  objects  when  a  new 
Version  is  generated. 

On  completion  of  (a  version  oQ  the  work- 
package,  the  information  would  be  te-Imported 
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io  beoauM  «  child  Vcnioii  of  the  ongiiiaL 

-  b  would  be  die  Secckn  Leeder’i  fiioGtioa  to 
iwiiiiileie  one  or  moie  of  dwie  duld-VcnkMi 
wark-peckage*.  lo  become  a  new  compoeiie 
Version  on  a  different  branch  of  the  nee. 
perhaps  for  export  to  the  superior  level  -  thus 
avoiding  the  classic  "lost  update"  situation. 

~  It  is  noted  that  the  above  scheme  exploits  the 
UNICON  stale-based  Version  facilities,  to 
avoid  the  necessity  for  checking-out  or 
“locking”  information  while  it  is  being  worked 
on  by  more  than  one  party. 

in  summary,  it  is  seen  that  state-based  Versioning  is 
inherently  capable  of  supporting  database  distribution  - 
a  branch  of  a  Version  tree  can  be  exported  to  a  sub¬ 
environment  where  it  becomes  the  root  of  a  new  tree. 
A  subsequent  operation  can  re-import  the  entire  tree,  to 
become  a  side-branch  of  the  original  parent  -  in  effect 
taking  delivery  of  both  the  enhanced  product,  and  of 
the  (suitably  pruned)  “lab  book”  for  audit  trail 
purposes. 

Besides  managing  its  own  object  libraries,  each 
SEGMENT  issues  its  own  (persistent)  surrogate 
database  Identifiers  for  ENTITIES/RELATIONS. 

The  path-name  or  “stem"  of  SEGMENT 
surrogate  Identifiers,  passes  through  the 
Configuration  of  the  superior  SEGMENTS,  this 
being  a  much  more  stable  route  which  is 
independent  of  the  actual  contents  of  these 
SEGMENTS. 

The  persistence  properties  required  of  surrogate 
identifiers,  mean  that  they  have  to  be  preserved 
without  change  through  all  database  versions  - 
and  through  all  Import/Export  operations.  This 
is  achieved  by  the  UNICON  database  using 
separate  orthogonal  coordinate  systems,  for  the 
surrogate  Identifiers  and  for  Version 
management. 

6.  COMPARISON  WITH  THE 

PUBLIC-TOOL-INTERFACE  APPROACH 
TO  STANDARDISATION 

The  European  ECMA  PCTE  programme,  and  the  US 
CAIS  programme,  are  both  based  on  the  concept  of  a 
Public  Tools  Interface  (PTI)  as  a  means  of 
Environment  standardisation.  The  notion  is  to  enable 
Environments  to  be  constructed  through  a  mix-and- 
match  selection  of  tools  from  different  vendors. 

The  idea  is  to  create  a  market  for  the  supply  of 
tools  which  will  be  able  to  inter-work. 

A  key  objective  is  to  achieve  "open” 
evolutionary  Environments  which  will  not  be 
dependent  on  any  one  supplier. 

However  it  has  to  be  borne  in  mind  that  the  defmition 
of  a  tool-coordination  interface  is  a  means  to  an  end  - 
the  activity  does  not  address  the  actual  problems  of 
producing  adequate  engineering  descriptions  and 
nuuiaging  their  development. 


-  It  cat  dtaeftMc  be  noied  that  a  staidaidiiatMn 
^iproach  baaed  on  fiading  a  sufficiealiy  geaeral 
engineeriag  deaciipticB  notalioii.  would  a  leaa 
have  the  virtue  of  focusing  attention  on  some  of 
the  actual  proUems  to  be  solved  -  as  has 
happened  in  UNICX)N  -  rather  than  on  some 
perceived,  but  remote,  enabling  technology. 

Ref  1  has  noted  that  despite  spending  “astounding” 
aoKxitus  of  money  over  a  ten  year  period,  large 
standardisation  initiatives  such  as  PCTE  and  CAIS 
have  yet  to  be  adopted  by  the  software  developmem 
oommunity  on  any  scale. 

-  They  go  on  state  that  the  basic  feasibility  of  a 
PTI  has  yet  to  be  proved,  there  being  a 
substantial  body  of  opinion  that  questions 
whether  it  is  yet  possible  to  defme  a  F^. 

This  Reference  also  notes  a  growing  acceptance 
that  only  a  core  of  functions  within  an 
Environment  have  to  be  tightly  integrated,  with 
application-specific  handlers  being  a  perfectly 
adequate  means  of  interfacing  many  loosely- 
coupled  tools. 

It  is  worth  considering  some  of  the  implied 
assumptions  behind  the  notion  of  a  Public  Tools 
Interface  -  that  separately  designed  tools  from  different 
vendors  can  mesh  together  closely  enough  to 
implement  the  core  of  an  Enviroiunent,  and  that  these 
core-tools  are  of  a  sufficient  value/complexity  to  be 
wonh  codifying  a  general  interface  defmition. 

It  is  argued  that  empirical  results  from  the 
UNICON  programme  undermine  both  of  the 
above  implied  assumptions;- 

In  UNICON  many  of  the  core  tools  merge 
together  to  such  an  extent  as  to  blur  their  very 
identities  -  eg  there  is  no  graphics  editor,  since 
this  function  is  incorporate)  within  the 
(separate)  database  input  and  the  database 
graphics  output  facilities.  Also,  Version 
management  is  meshed  so  closely  with  database 
segmentation  and  with  Import/Expon  functions, 
much  of  it  having  to  meet  demanding  real-time 
User-response  constraints,  that  it  is 
inconceivable  that  separate  vendors  could  have 
been  involved  in  any  one  implementation. 

~  On  the  other  hand,  the  UNICON  work 

demonstrates  that,  with  a  simple  notation  of 
sufficient  scope,  the  core  of  an  Environment  can 
consist  of  about  50k  lines  of  very  modular 
source  code.  (This  estimate  is  based  on  a 
generous  extrapolation  from  the  30k  line  size  of 
the  current  UNICON  system.)  Qearly  it  would 
never  be  worth  trying  to  factorise  such  a  small 
core  programme,  with  a  view  to  multi-vendor 
implementation. 

Finally  it  is  noted  in  passing,  for  what  it  is  worth,  that 
the  specifications  for  PCTTE  and  CAIS  interfaces  are 
some  500  and  1100  pages  respectively,  per  language 
binding. 
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-  As  mirlinwl  above,  the  UNICON  oonfonnaaoe 

would  pfobubly  lua  lo  about  10 
pages  -  from  which,  together  with  tome 
descriptive  material,  any  group  should  be  able 
to  write  their  own  o^omiing  UNICON 
Environmeat,  in  the  language  of  their  choice. 

7.  DISCUSSION 

7.1  Dots  Unicon  Include  Sufficient  Functions  To 

Be  An  Adequate  Core  For  A  Software 
Engineering  Environment  f 

UNICON  is  based  upon  a  simple  engineering  notation, 
which  is  directly  mapped  onto  a  file-store  to  become  a 
database  with  a  graphics  User  interface.  An  additional 
reference  system  supports  database  segmentation  and 
distribution,  as  an  integral  part  of  the  version 
management  function.  However,  even  if  the  scope  and 
integration  of  these  important  facilities  are  accepted, 
there  remains  some  question  as  to  whether  they  are  in 
harmony  with  the  provision  of  other  necessary 
facilities. 

eg  project  management,  security,  E-Mail 
conununications.  User  object-typing, 
application-specific  rule-sets,  etc  etc. 

It  is  taken  as  being  self-evident  that  a  Standard  should 
confine  itself  to  the  bare  minimum  of  concepts  and 
detail,  sufficient  to  meet  its  declared  objectives  -  by 
focussing  on  essentials,  it  will  broaden  its  scope. 

The  UNICON  conformance  proposals  are  held 
to  agree  with  this  principle,  with  the  sole 
declared  objective  being  the  uansfer  of 
application  work-packages  between  UNICON 
environments,  using  the  defined  notation. 

In  following  this  minimal  approach  to  Standardisation, 
the  only  rationale  for  extending  the  scope  of  the 
UNICON  conformance  definition,  would  be  to  achieve 
a  desired  degree  of  integration  of  some  excluded 
facility,  which  could  not  readily  be  done  by  other 
means  -  eg  using  a  handler. 

Whilst  it  would  be  bold  to  say  that  UNICON  as  it 
stands  already  addresses  all  of  the  functions  which 
have  to  be  closely  integrated,  it  is  certainly  the  case 
that  none  of  the  areas  already  considered  would  come 
within  this  core-function  category 

-  This  situation  is  probably  due  to  the  extreme 
generality  of  the  UNICON  notation  (with 
conventional  ENTmES/RELATIONS  being 
available  as  a  degenerate  case  of  the 
extensions),  the  generic  level  of  operation  of  the 
UNICON  tools,  and  the  flexibif  y  of  the 
ATTRIBUTE  management  arrangements. 

-  For  example,  it  would  be  open  to  any  UNICON 
implementation  to  define  application-specific 
ATTRIBUTE  fields,  together  with  associated 
rule-sets  -  eg  for  ENTITY  typing.  This 
information  would  be  compatible  with  the 
standard  Import/Export  format,  where  it  would 
be  transferred  anonymously  as  ATTRIBUTE 
byte-stream  data.  (This  would  in  no  way  be  a 


riiady  praciioe,  ainoe  oomptunicarioB  between 
any  two  cnviraniiiena  will  alw^rs  lequin  wiMg 
fonn  of  shared  ooniext  -  eg  contmon  knowledge 
of  HOOD.  ADA.  etc). 

In  Aunmary.  it  is  argued  that  if  UNICON  were  to 
become  a  Standard  along  the  proposed  lines,  the  atent 
not  coveted  (such  as  Projea  Management  etc)  would 
become  the  subject  of  what  is  known  in  the  US  as  an 
"after-markei*'  of  suppliers  -  without  in  any  way 
compromising  the  Standardisation  objectives. 

-  However  there  is  probably  a  good  case  to  be 
made  for  defining  a  small  standard  set  of 
navigation-type  database  query  functions,  for 
use  by  loosely-coupled  tools. 

7JI  ^‘A  Software  Engineering  Environment  Is  A 
Large  Complex  Piece  Of  Software  Bfkick  Hat 
Been  Compared  To  An  Operating  System  And 
A  Database  Rolled  Into  One" 

Whilst  versions  of  the  above  statement  find  their  way 
into  the  literature  as  throw-away  truisms,  the  present 
paper  has  argued  that  such  complexity  need  not  be  the 


There  seems  to  be  a  paradox  in  which  some 
problems  can  be  almost  intractable  when 
considered  in  isolation  -  eg  the  design  of  a 
general  Version  Management  function  -  yet 
when  addressed  within  an  appropriate  context,  a 
solution  can  readily  be  found  which  is  both 
trivial  to  implement,  and  delivers  an 
unexpectedly  large  functionality,  due  to  mutual 
interaction  within  the  context. 

The  design  of  Software  Environments  seems  to 
be  panicularly  prone  to  the  above  paradox.  The 
situation  ha-s  been  likened  within  the  literature 
(Ref  4)  to  constructing  a  bridge  across  a  chasm 
-  the  whole  is  very  much  greater  than  the  sum 
of  die  parts,  if  you  set  out  with  concepts  of 
insufficient  scope,  you  will  end  up  worse  off 
than  if  you  had  not  started  in  the  first  place. 

There  is  no  fund^.,nental  reason  why  a  Software 
Environment  liaving  only  50k  lines  of  code,  cannot 
deliver  a  functionality  well  beyond  any  yet  available. 

7J  'The  Introduction  Of  A  Software 

Environment  Into  An  Organisation  Will 
Inevitably  Require  Significant  Changes  In 
Their  Development  And  Management 
Procedures" 

It  is  now  widely  recognised  that  the  introduction  of 
new  work-practices/tools  to  a  large  organisation, 
involves  timescales  measured  in  years  rather  than 
months.  It  may  therefore  be  a  pragmatic  stratagem  that 
UNICXIN’s  flexibility  should  be  exploited  in  the  first 
instance  to  emulate  the  existing  working  practices  - 
warts  and  all. 

~  The  notion  is  to  regard  the  putting  in  place  of 
the  resources  to  support  evolution,  as  a  separate 
objective  in  its  own  right,  to  be  done  with  the 
absolute  minimum  of  disruption  and  change. 
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-  After  M  k)^  a  period  M  it  takes  to  achieve 
fteniliariaation.  evoluttoa  could  Ikea  bepa  - 
with  aa  appropriate  involveaieat  aad  coaeaneue 
at  the  whole  oaoununity  with  regaid  to 
diiectioo  and  pace. 

-  In  the  case  of  the  UNICON  revcne^gineering 
experiment  repotted  above,  it  would  be  quite 
pocsible  to  introduce  UNICON  as  uy  a  simple 
Graphics  tool  and  a  Versioning  aid  to  die 
existing  development  processes.  In  time,  the 
automatic  generation  at  the  batch  commaitd 
files  would  be  introduced  -  as  a  checking 
operation  for  the  manual  work  ....  and  so  on  a 
step  at  a  time. 

As  well  as  being  able  to  precisely  emulate  existing 
methodologies  and  practices,  UNICON  also  has 
significant  rationalisation  capabilities:- 

MASCOT  is  an  elegant  design/implementation 
methodology,  of  some  twenty  years  standing, 
where  asynchronous  “ACTIVITY”  threads 
communicate  through  “CHANNEL”  letter-box 
buffers.  From  the  UNICON  perspective,  it  is 
argued  that  the  designers  of  the  later 
MASCOT3  sub-system  extensions  have  been 
profligate  in  their  coining  of  new  language 
concepts  and  keywords,  and  have  placed 
onerous  demands  on  the  User  in  requiring  so 
many  items  to  be  given  names.  Since  UNICON 
can  provide  a  much  more  comprehensive  set  of 
sub-system  constructors,  in  a  general  way 
which  would  none  the  less  generate  the  desired 
MASCOT  network  (along  the  lines  of  Fig  7),  it 
is  held  that  many  of  the  new  MASCOT3 
“concepts"  can  now  be  regarded  as  being  to  do 
with  implementation  rather  than  functionality. 

A  not  dissimilar  point  can  be  made  with  respect 
to  the  somewhat  ill-defined  HOOD 
methodology.  The  aim  here  wis  to  introduce 
levels  of  hierarchy  above  the  OOD  code 
modules,  through  the  introduction  of  pseudo 
objects  -  although  they  looked  like  normal 
objects  from  the  outside,  their  services  were 
actually  provided  by  nested  OOD  objects.  Once 
again  UNICON  can  provide  these  hierarchical 
subsystem-type  levels  within  a  much  more 
general  context  -  which  can  of  course  include 
the  more  restricted  HOOD  psuedo- object 
formulation  as  a  sub-set  if  desired. 

8.  FUTURE  UNICON  WORK 

The  aims  of  this  paper  have  been  to  present  a  new 
approach  to  the  through-life  support  of  large  software- 
intensive  systems.  This  led  to  the  development  of  an 
engineering  description  notation,  and  its  subsequent 
application  to  Software  Environment  design,  and  to 
standardisation  proposals. 

The  Defence  Research  Agency  is  continuing  with  the 
codification  and  evaluation  of  UNICON,  for  possible 
use  by  the  Ministry  of  Defence.  The  importance  of 
adhering  where  possible  to  widely  accept^  practices 
and  standards  is  of  course  recognised  -  to  this  end  the 
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DRA  uwiiM  commenu  and  criticism  of  the  UNICON 
work,  aad  views  on  wiiedier  it  is  likely  to  attract  a 
wider  imerest 

On  the  assumption  that  this  work  will  eventually  have 
a  wider  appUcadon,  the  Defence  Research  Agency 
would  be  inteiested  to  hear  from  any  party  which 
wishes  to  be  involved  in  the  evaluation,  codification,  or 
sponsorship  of  UNICON  as  a  possible  standard,  or  to 
have  earlier  access  to  the  techn^ogy. 

9.  POSTSCRIPT 

Dear  Reader,  if  you  believe  that  the  development  of  the 
UNICON  concepts  actually  followed  the  logical 
sequence  outlined  above,  then  to  echo  the  reply  by  the 
Duke  of  Wellington  when  addressed  by  a  stranger  in 
his  club  as  “Mr  Smith  I  believe”  -  “if  you  believe  that 
you  will  believe  anything”. 
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SUMMARY 

The  software  process  consists  of  the  methods,  practices  and 
tools  used  to  generate  a  software  product.  The  Software  Engi- 
neermg  Institute  at  Carnegie  Mellon  University  has  developed 
a  Capability  Matunty  Model  (CMM)  which  defines  five  levels 
of  maturity  for  the  software  process.  Also  included  are  sets  of 
entena  that  allow  the  specific  assessment  of  actual  software 
engineenng  matunty  in  given  projects  or  organizations. 

In  areospace  projects,  software  engineering  very  often  is  cou¬ 
pled  with  or  embedded  in  systems  engineenng.  It  is  therefore 
desirable  to  know  if  and  how  the  CMM  can  be  extended  to  sy¬ 
stems  enguieenng.  The  paper  shows  that  this  approach  is 
feasible. 

After  a  brief  summary  of  the  origmaJ  Capability  Maturity  Mo¬ 
del  an  overview  and  comparison  of  software  and  systems 
engineering  disciplines  is  provided.  Differences  between 
software  and  systems  engineering  are  highlighted  and  modifi¬ 
cations  are  proposed  to  adapt  and  generalize  the  CMM  accor¬ 
dingly. 

Finally,  the  framework  for  a  Systems  Engineering  Matunty 
Model  IS  presented.  This  model  is  intended  as  a  reference 
scale  for  systems  engineering  capability,  in  a  similar  way  as 
the  CMM  applies  to  the  .software  process. 

I.  GOALS 

During  the  course  of  our  activities  in  systems  engineenng  we 
became  aware  of  the  work  of  the  Software  Engineenng  Insti¬ 
tute  (SEI)  at  Carnegie  Mellon  University.  They  have  develo¬ 
ped  a  framework  for  assessing  the  maturity  of  the  software 
process  in  a  given  organization. 

On  the  other  hand,  from  our  experience  with  many  providers 
and  users  of  systems  engineering  products  and  services  in  the 
public  and  private  sectors  of  several  countries,  we  knew  that  a 
corresponding  method  is  lacking  for  the  evaluation  of  systems 
engineering  maturity.  Thus  we  have  aimed  this  article  at  those 
who  are,  as  we.  looking  for  a  framework  to  evaluate  and  im¬ 
prove  the  competitiveness  of  the  systems  engineering  process. 

The  goals  of  this  paper  are  twofold.  The  first  is  to  provide  a 
framework  for  assessing  systems  engineering  maturity  and  to 
identify  the  critical  process  areas  in  which  improvement 
would  raise  the  overall  process  to  a  higher  level  of  excellence. 
The  second  goal  is  to  stimulate  further  work  ui  the  develop¬ 


ment  and  application  of  methodologies  to  assess  and  improve 
the  practice  of  systems  engineering 

Before  addressing  these  goals,  a  brief  review  of  software  and 
systems  engineenng  is  provided.  This  estabhshes  a  common 
basis  for  comparison  of  the  two  disciphnes  and  serves  as  a 
bridge  fur  the  generalization  of  the  SEI  Capabihly  Maturity 
Model  from  software  engmeeruig  to  systems  enguieermg. 

We  are  aware  that  there  may  be  shortcomings  in  this  attempt, 
but  we  are  hopeful  that  our  prelimuiary  results  will  be  accep¬ 
ted  within  the  scope  of  this  article 

X  REVIEW  OF  THE  SEI  CAPABILITY  MATURITY 
MODEL 

The  software  process  consists  of  the  methods,  practices  and 
tools  applied  m  the  course  of  a  project  to  generate  a  software 
product.  In  November  1986.  the  Software  Engineering  Insti¬ 
tute  (SEI)  at  Carnegie  Mellon  University  (CMU).  with  assi¬ 
stance  from  the  MITRE  Corporation,  began  developmg  a  fra¬ 
mework  that  would  allow  organizations  to  assess  the  maturity 
of  their  software  process  (Ref.  1)  The  initial  framework  soon 
evolved  into  a  comprehensive  matunty  model  (Ref.  2.  3), 

Figure  1  shows  a  summary  of  the  model.  It  is  charactenzed  by 
five  levels  of  software  enguieermg  matunty,  the  lowest  being 
level  1.  Initial  and  the  highest  being  5,  Optimizing  The  un- 
derlymg  philosophy  for  the  charactenstics  of  the  five  levels  is 
to  look  at  the  features  of  the  software  process  in  terms  of; 

Process  Procedures 

Process  Performance 

Engineering  Style. 

The  maturity  of  the  process  procedures  is  rated  according  to 
the  degree  of  systematic  approach,  and  of  support  by  state-of- 
the-art  tools  and  automation.  At  level  I  no  formalized  rules 
are  practiced,  at  level  2  experience  is  passed  on  orally,  at  level 
3  proven  [vocedures  are  laid  down  in  written  form,  at  level  4 
the  emphasis  is  on  process  metrics  and  at  level  5  a  self -opti¬ 
mizing  mechanism  is  reached  for  the  process. 

The  matunty  of  process  performance  is  judged  by  the  devia¬ 
tion  of  the  actual  process  results  from  the  planned  goals  of 
productivity  and  quality.  The  higher  the  maturity  level,  the 
less  IS  the  risk.  i.  e.  overruns  become  consistently  smaller  and 
estimates  get  more  and  more  reliable. 
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Process  unpredictable 


Figure  1 .  Levels  of  Capability  Maturity  Model 


The  maluhty  of  engineering  style  is  often  loosely  characteri¬ 
zed  as  progressing  from  (1)  the  "aeative  artist  "  via  (2)  the 
tnbal  group ",  (3)  a  "corporate  identity""  and  (4)  "professional 
leadership"  up  to  (5)  the""  software  factory"". 

The  Key  Process  Areas  in  figure  I  constitute  the  practices  that 
must  have  been  implemented  in  the  software  process  ui  order 
to  qualify  for  levels  2,  3,  4  and  5  respectively.  There  are  no 
requirements  for  level  1 . 

The  fully  developed  Capability  Maturity  Model  (CMM)  is 
augmented  by  a  set  of  instruments  for  the  actual  assessment 
procedure: 

Description  of  Maturity  Level  Characteristics 
Description  of  Key  Process  Areas 
Maturity  Questionnaires 
Respondent"s  Questionnaire 
Project  Questionnaire. 

At  each  level  the  appropriate  key  process  areas  are  addressed 
by  the  Maturity  Questionnaires.  These  questionnaires  probe 
for  the  process  characteristics  of  every  level  from  2  upwards. 
Usually  a  software  producing  unit  begins  its  assessment  with 
the  test  for  level  2.  Only  when  this  test  has  been  passed  to 
complete  satisfaction,  the  next  test  for  level  3  will  be  conduc¬ 
ted,  and  so  on.  No  level  may  be  skipped.  The  Respondent"s 
Questionnaire  is  used  to  describe  the  professional  background 
of  the  person  completing  the  the  maturity  questionnaire.  The 
Project  Questionnaire  is  applied  to  characterize  the  project  for 
which  the  maturity  questionnaire  is  being  completed. 


The  relationship  of  the  various  concepts  used  in  this  context  is 
illustrated  in  figure  2  (Ref.  3). 

"The  key  process  areas  identify  the  requirements  for  each  ma¬ 
turity  level,  i.e.  they  defme  the  enabling  practices.  The  process 
maturity  reflects  an  Drganization"s  ability  to  consistently  fol¬ 
low  and  improve  its  software  engineering  process,  i.e.  it  indi¬ 
cates  to  which  degree  the  enabling  practices  are  actually  un- 
plemented.  The  process  capability  is  the  range  of  results  ex¬ 
pected  from  following  the  implemented  process,  i.e.  it  predicts 
future  project  outcomes.  The  process  performance  cha¬ 
racterizes  the  actual  results  achieved  from  following  the  pro¬ 
cess. 
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Figure  2.  SEI  Process  Maturity  Framewoik 
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3.  SCOPE  OP  SOFTWARE  ENGINEERING 
Software  consists  of  computet  pcognms,  procedures,  asso¬ 
ciated  documentation  and  data  pertaining  to  the  operation  of  a 
computer  system.  Software  Engineering  is  the  application  of  a 
systematic,  disciplined  and  quantifiable  approach  to  the  deve¬ 
lopment,  operation  and  maintenance  of  software  (Ref.  4). 

As  we  will  see  in  section  4,  software  constitutes  a  subset  of 
the  set  of  basic  elements  of  a  general  system.  Almost  absent  in 
the  systems  of  the  early  fifties,  software  quickly  began  to  take 
over  evo:  increasing  parts  of  system  functions.  The  growth  of 
software  was  so  fast  that  the  "software  crisis"  developed  (Ref. 
5).  As  a  consequence  great  efforts  were  triggered  to  drive 
software  activities  from  a  kind  of  creative  ail  to  a  branch  of 
engineering.  In  1985  the  [X)U-STD-2167  on  Software  Deve¬ 
lopment  was  issued,  marking  a  similar  milestone  for  software 
engineenng  as  did  the  MIL-STD-499  for  systems  engineering. 

A  summary  of  the  relevant  concepts  and  terms  of  the  current 
revision  A  of  DOD-STD-2167  (Ref.  6)  is  given  in  figure  3. 

In  order  to  correlate  with  the  scope  of  systems  engineering,  we 
refer  to  the  statement  in  DOO-$TD-2I67A  that  it  should  be 
used  m  conjunction  with  MIL-STD-499  for  total  system  de¬ 
velopment.  In  this  context  we  have  defmed  the  scope  of  Soft¬ 
ware  Engmeenng  as  shown  in  figure  4.  (The  figure  as  such  is 
not  part  of  2167A,  but  has  been  set  up  to  match  figure  5). 

The  Software  Elements  under  consideration  are  those  mentio¬ 
ned  at  the  head  of  this  section  plus  the  software  elements  of 
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Figure  3.  Summary  of  Software  Development 

fiimware.  The  hardware  elements  of  firmware  are  not  inclu¬ 
ded. 

The  mput  to  all  the  tasks  ui  figure  4  are  the  customer  needs 
only  in  the  case  that  the  software  system  is  a  stand-alone  deli¬ 
verable  Item.  Often  the  software  is  embedded  in  a  wider  sy- 


Then  the  input  to  the  software  tasks  are  the  software  requi¬ 
rements  and  applicable  portions  of  the  system  requuements. 
These  are  the  results  of  the  first  steps  of  the  systems  en¬ 
gineenng  process.  The  outpul  of  the  activities  in  figure  4  mat¬ 
ches  figure  5.  but  is  confined  to  software  only. 

Regarding  the  prunaiy  functions  of  figure  4.  only  Develop¬ 
ment  and  Suf^rt  of  software  systems  are  explicitly  mentio¬ 
ned  in  2167A  (besides  acquisiuon).  But  taking  into  account 
the  statement  that  it  should  be  used  in  conjunction  with  MIL- 
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STD-499,  the  primaiy  functions  of  the  latter  standard  have 
been  earned  over.  Only  the  term  "Manufacturing"  of  the  over¬ 
all  system  (meaning  fabrication  and  assembly  of  test  models 
as  well  as  low-rate  initial  ami  full-rate  senes  producuon)  is  re¬ 
placed  in  this  paper  by  the  term  "Implementation",  i.e.  coding 
and  integration  of  the  software  system. 

The  term  software  engineering  process  does  nut  appear  in 
UOD-STD-2167A.  This  standard  speaks  of  the  Software  De¬ 
velopment  Process  and  of  Software  Engineering,  see  figure  3. 
Looking  at  the  eight  steps  of  the  software  development  pro¬ 
cess,  one  can  associate  the  last  four  steps  to  implementation 
and  test  ("manufacturing"  and  "verification").  The  first  four 
steps  bear  a  resemUance  to  the  systems  engineering  process. 
They  are  therefore  presented  m  figure  4  under  the  name  of 
"Software  Engineering  Process". 

The  Acquisition  Phases  correspond  directly  to  those  of  sy¬ 
stems  engmeenng.  Only  the  development  of  manufacturmg 
installations  can  be  ommitted  because  the  series  production  of 
software  reduces  to  the  simple  act  of  copying. 

4.  SCOPE  OF  SYSTEMS  ENGINEERING 
The  term  of  Systems  Enguieenng  ongmated  only  some  deca¬ 
des  ago  in  the  aerospace  field.  During  the  sixties  this  disci¬ 
pline  reached  a  high  level  of  professional  standard,  promoted 
especially  by  such  large-scale  endeavours  as  the  Apollo  pro¬ 
ject.  In  1969  the  MIU-STD-499  on  Engineenng  Management 
was  developed  by  the  USAF  to  form  a  first  milestone  in  defi¬ 
ning  and  unifying  the  associated  basic  concepts  and  procedu¬ 
res.  The  current  revision  A  is  directed  at  all  of  DoD  systems 


engineenng  as  well  as  jomt  Government-industry  contracts 
(Ref  7). 

In  these  days,  revision  B  of  MIL-STD-499  IS  being  prepared, 
with  the  modified  title  of  Systems  Engineering  (Ref  8).  Ac¬ 
cordingly,  a  System  is  an  integrated  cumpusile  of  products, 
processes)  oiid  people  that  provide  a  capability  lo  satisfy  a  sla¬ 
ted  need  or  objective.  Systems  Engineenng  is  an  mter 
disciplinaiy  approach  lu  evolve  and  verity  an  integrated  and 
bfe-cycle  balanced  set  of  system  product  and  process  soluti¬ 
ons  that  satisfy  customer  needs. 

M1L-STD-499B  defines  the  scope  of  Systems  Engmeenng  as 
shown  m  figure  5.  The  physical  scope  of  any  system  is  deb- 
neated  by  the  configuration  of  its  System  Elements,  i.e  its 
basic  constituents:  Hardware.  Software.  FacibUes.  Personnel. 
Data,  Matenal.  Services,  or  Techniques. 

For  all  of  these  system  elements  the  Systems  Engmeer  has  to 
consider  three  aspects,  formmg  the  three  axes  of  the  cube  m 
figure  S.  i.  e.  Primaiy  Functions.  Acquisition  Phases  and  the 
Systems  Engineenng  Process. 

The  eight  primary  funcuons  are  those  essential  tasks,  actions 
or  activities  that  must  be  accompUshed  to  ensure  that  the  sy¬ 
stem  will  satisfy  customer  needs  during  the  total  bfe-cycle. 

The  five  acquisition  phases  cover  the  evolution  of  the  project, 
after  the  pre-concept  tasks  of  assessmg  technological  opportu¬ 
nities  and  formulating  the  customer  needs,  and  before  the 
post-operation  tasks  of  decommissiomng  and  disposal. 


Output 

O 

Life  Cycle 
Balanced 
Products  & 
Processes 


System 

Elements: 

•  Hardware 

•  Software 

•  Facilities 

•  Personnel 

•  Data  etc. 


Figure  5.  Scope  of  Systems  Engineering 


28-.S 


The  four  consecutive  steps  of  the  systems  engineering  process 
are  Requirements  Analysis  (incl.  dermition  of  constraints, 
measures  of  eHectiveness,  functional  and  performance  requi¬ 
rements),  Functional  Analysis  and  Allocation  (uicl.  top-down 
decomposition  of  the  functional  architecture  and  requirements 
flow-down).  Synthesis  (i.e.  the  translation  of  functions  and 
requirements  into  solutions  in  terms  of  the  system  elements), 
and  Systems  Analysis  and  Control  (w.r.t.  the  measures  of  sy¬ 
stem  and  cost  effectiveness  and  to  the  system  configination). 

The  systems  engineering  process  is  applied  to  all  relevant  pri¬ 
mary  functions  of  the  system  life  cycle.  The  initial  nin  of  this 
process  is  started  and  performed  in  the  fust  acquisition  phase 
and  IS  then  iterated  during  each  succeeding  phase.  Note  that  it 
is  not  sufficient  to  do  the  process  only  for  the  operational 
requirements  and  only  once  ui  the  definition  phase  (as  marked 
by  the  shaded  bar  in  the  foreground  of  figure  S),  although  this 
IS  usually  considered  to  be  the  most  important  process  part. 

It  IS  evident  that  the  scope  of  systems  engineering  is  quite 
large  and  that  the  required  job  is  very  demanding.  Note  that 
the  above  formulations  follow  the  draft  of  revision  B  of  MIL- 
STD-499.  Compared  to  the  current  revision  A  the  following 
extensions  have  been  introduced: 

System  Elements;  "Procedural  Data"  have  been  replaced 
by  "Data,  Material,  Services,  or  Techniques". 

Prunary  Functions:  Development,  Traimng  and  Diposal 
functions  have  been  added.  These  will  generate  their  own  spe¬ 
cific  requirements,  e.g.  on  CASE  tools,  training  facilities,  or 
materials  that  can  be  safely  discarded  or  recycled. 

Systems  Engineering  Process:  "Mission  Requirements 
Analysis"  has  been  generalized  to  "Requirements  Analysis". 
"Functional  Analysis"  and  "Allocation"  have  been  combined 
into  one  step,  and  "Systems  Analysis  and  Control"  has  been 
added.  So.  even  if  there  still  are  four  steps,  the  work  involved 
has  expanded  considerably. 

5.  SOFTWARE  ENGINEERING  VERSUS  SYSTEMS 
ENGINEERING 

Software  engineering,  although  having  started  later  than  sy¬ 
stems  engineering  and  suffering  from  a  high  pace  of  ever  in¬ 
creasing  volume,  has  made  considerable  progress  since  the 
software  crisis  was  identified  in  1968. 

Meanwhile,  software  engineering  has  been  catching  up  in 
formal  procedures  with  systems  engineering.  In  some  aspects 
It  even  surpassed  systems  engineering.  The  authors  became 
aware  of  this  when  they  learned  about  the  Capabilty  Maturity 
Model  (CMM).  Such  a  model  does  not  exist  for  systems 
engineering.  We  believe  that  it  will  be  very  beneficial  to  ob¬ 
tain  a  similar  model  for  systems  engineering,  for  several 
reasons: 

The  CMM  provides  a  standard  bv  which  each  project,  di¬ 
vision  or  company  can  measure  its  pioiessional  competence  in 
software  engineering.  From  the  detected  deficiencies  actions 
for  improvement  can  be  derived. 


SuKX  the  ChtM  already  contains  some  key  areas  ihai  are 
also  part  of  systems  engineering  (requirements  management, 
quality  assurance.  configuraUon  management  etc.)  it  may  he 
considered  as  a  basis  fur  generalization. 

The  scope  of  systems  engineering  is  beuig  mute  piecisely 
defined  and  slightly  extended  by  the  new  dralt  of  MIL-STD- 
499B. 

The  demands  on  systems  engineering  are  becoming  mure 
challenging  due  to  recent  developments  in  the  military  and 
commercial  acquisition  envuonmeni  (incieased  competition, 
lean  production,  design  to  life-cycle  cost,  concunent  en¬ 
gineering.  CALS  etc.) 

The  resources  of  systems  enguieering  are  greatly  rnipro- 
ving  due  to  more  powerful  and  cost-effective  development  en¬ 
vironments.  Modern  computer-aided  systems/suflware  engi- 
neenng  (CASE)  tools  allow  to  master  more  complex  systems 
using  elaborate  formal  system  descnplion  and  design  tools. 

A  framework  for  benchmarking  and  unproving  systems 
engineering  will  probably  have  a  sunilar  impact  on  raisutg  the 
overall  competence  in  systems  enguieenng  as  the  CMM  dues 
m  the  field  of  software  enguieenng. 

At  the  intent  of  generalizing  the  CMM  from  software  to  sy¬ 
stems  engmeenng,  some  caution  is  appropnate: 

Software  engineering  is  only  a  part  of  systems  engmeenng 
and  this  part  is  sometimes  small,  see  figure  6 

Software  elements  are  usually  only  a  subset  of  all  system 
elements,  see  section  4. 


•  • 


Figure  6.  Systems  vs.  Software  Engineering 
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Hardware  etements  have  features  and  processes  different 
or  absent  from  software  elements.  A  good  example  is  the  pro¬ 
blem  of  series  production,  i.e.  copying  the  prototype  system  to 
full-rate  quantities  for  deployment  and  fielding. 

The  CMM  is  accompanied  by  detailed  questionnaires  to 
evaluate  compliance  with  the  capability  requirements  at  each 
of  the  upper  four  levels  of  competence. 

Nevertheless,  the  authors  feel  that  the  CMM  is  a  good  starling 
point  for  a  Systems  Engineering  Maturity  Model. 

In  the  effort  to  transfer  and  generalize  the  CMM  from  soft¬ 
ware  engineering  to  systems  engineering  we  use  the  concepts 
of  software  enguieering  and  systems  engineering  in  the  sense 
of  LX)D-STD-2167A  and  MIL-STD-4<WB  (draft)  respecti¬ 
vely,  see  sections  3  and  4.  We  are  aware  that  neither  of  these 
standards  is  universally  recognized.  But  both  standards  are 
widely  known,  and  they  are  practically  applied  or  tailored  for 
many  projects.  Thus  they  provide  a  valuable  common  lan¬ 
guage  to  discuss  the  systems  and  software  engineering  para¬ 
digms. 

6.  SUITABILITY  OF  THE  CMM  WITH  RESPECT  TO 
SYSTEMS  ENGINEERING 

The  SEI  Maturity  Model  has  already  been  applied  to  many 
software  organizations.  So.  on  the  one  hand  it  has  been  reali¬ 
stically  validated  and,  on  the  other  hand  it  has  efficiently  con- 
Inbuted  to  the  improvement  of  the  software  process  in  the 
assessed  software  producing  units. 

But  no  tool  set  is  perfect  and  the  CMM.  too.  has  its  detractors. 
.Some  cntics  have  expressed  concern  that  it  fails  to  recognize 
the  impact  of  competent  and  motivated  individuals  and  multi- 
discipline  teams  on  reducing  risk  and  increasing  productivity 
and  qualify  The  SCI  acknov.  ledges  that  "the  CMM  is  not  a 
silver  bullet  and  does  not  address  all  of  the  issues  that  are  im¬ 
portant  for  successful  projects"  (Ref.  9). 

Nevertheless,  the  authors  consider  the  software  engineering 
CMM  as  a  good  basis  for  generalization  m  the  direction  of  a 
corresponding  model  for  systems  engineering. 

To  test  our  premise  that  the  CMM  is  indeed  suitable  for  this 
purpose,  SEI  and  nine  of  its  Software  Process  Assessment 
Associates  were  requested  to  review  and  comment  on  our 
preliminary  draft  model. 

Responses  were  received  from  SEI  (informal).  Pragma  Sy¬ 
stems  Corporation,  Dayton  Aerospace  Associates  and  Ameri¬ 
can  Management  Systems.  The  three  assessment  associates 
provided  encouragement  and  valuable  written  comments;  all 
four  respondents  indicated  that  our  premise  was  feasible. 
Then'  constructive  contributions  have  been  incorporated  in  the 
present  article. 

7.  PROPOSED  SYSTEMS  ENGINEERING  MATURITY 
MODEL 

The  inputs  received  from  the  three  assessment  associates  and 
our  own  continuing  work  suggest  that  adaptations  of  the 


SEI  model  to  systems  enguieenng  must  go  beyond  those 
presented  in  this  paper.  However,  we  believe  to  have 
established  a  baseline  from  which  one  can  proceed  further  to 
develop  the  Systems  Enguieenng  Matunty  Model  to  the  full 
extenL 

The  present  status  of  the  Systems  Engineering  Maliinly  Model 
(SEMM)  IS  given  by  figure  7.  The  sumlanties.  modifications 
and  additions  with  respect  to  the  Software  Capability  Maturity 
Model  (CMM)  are  apparent  from  a  cumpanson  between  the 
figures  I  and  7. 

The  basic  features  have  been  earned  over  unchanged  from  the 
CMM  to  the  SEMM,  because  they  are  proven  and  apply 
equally  to  both  software  and  sysbims  engineering  discipbnes. 
Moreover,  it  was  the  intention  of  the  authors  to  keep  as  much 
consistency  as  possible  between  both  models.  Therefore  the 
principle  of  five  matunty  levels,  the  designation  of  the  levels 
and  the  characteristics  of  the  levels  have  been  retained. 

Changes  have  been  entered  to  the  key  process  areas  by  a  trans¬ 
formation  ui  three  steps.  First  the  KPA  s  have  been  generali¬ 
zed  en  bloc  from  software  to  systems. 

Then  it  was  checked  for  each  ICPA  whether  this  step  is  valid 
with  or  without  modifications.  And  finally,  new  key  process 
areas  have  been  added  where  deemed  necessary.  The  additions 
are  mainly  due  to  the  fact  that  systems  enguieeruig  covers  a 
wider  scope  than  software  engmeermg,  see  section  5 

The  KPA's  to  be  mastered  in  order  to  qualify  for  level  2  have 
been  augmented  by  one  area,  i.e.  System  Risk  Management. 

For  the  level  3  KPA's  the  modifications  are;  extension  of 
"Training"  to  include  "Education",  extension  of  "Reviews"  to 
include  "Testing",  replacement  of  "Intergroup  coordination" 
by  "interdiscqihnary  group  coordination",  generalization  of 
"Software  product  engineenng"  to  "Life-cycle  balanced  pro¬ 
duct  engineering"  (see  figure  5)  and  of  "Integrated  software 
management"  to  "Integrated  systems  management ". 

Only  minor  modifications  were  made  for  the  level  4  KPA's; 
the  wording  was  chosen  to  be  more  concrete. 

The  first  of  the  level  5  KPA's  was  generalized  from  "Defect 
prevention"  to  "System  problem  prevention",  the  second  KPA 
canies  directly  over,  and  the  third  KPA  was  expressed  in  a 
slightly  more  general  way.  On  level  5  the  focus  is  on  automa¬ 
tion  and  integrated  computer-aided  systems  engineenng  (not 
shown  in  figure  7). 

Note  finally  that  the  benefit  of  "Increased  Productivity  and 
(Quality"  of  the  SEI  model  has  been  replaced  by  "Increased 
Customer  and  Producer  Satisfaction"  to  reflect  a  more  general 
view  of  quality  and  productivity.  Systems  engineering  at  a 
high  maturity  level  delivers  products  and  services  which 
match  the  needs  of  the  customer,  and  does  so  reliably  within 
narrow  gotds  of  cost  and  time  schedule. 
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Maturity  Level 

Characteristics 

Key  Process  Areas 

5 

Optimizing 

Feedback: 

Process  continuously 
improved 

System  problem  prevention 

Technology  innovation 

Process  management 

4 

Managed 

Quantitative: 

Process  measured 
Focus  on  metrics 

Process  mapping  /  variation 

Process  improvement  data  base 
CXiantitative  quality  plans 

3 

Defined 

Qualitative. 

Process  defined  & 
institutionalized 

Focus  on  process  org. 

Organizational  process  definition 
Education  and  training 

Reviews  and  testing 

Interdisciplinary  group  coordination 

LC  balartced  product  engineering 
Integrated  systems  management 

2 

Repeatable 

Intuitive; 

Process  dependent 
on  individuals 

Focus  on  proj.  mgmt. 

System  requirements  management 
Project  planning  and  tracking 
Subcontract  management 

System  configuration  management 
Quality  assurance 

System  risk  management 

Increased 

OMoamA 

Producer 

Satisfactian 

I 

Reduced 

Risk 

I 


1  initial  Ad  hoc  /  chaotic; 

Process  unpredictable 


4 


0 
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Figure  7.  Systems  Engineering  Maturity  Levels 


8.  COMPLETING  THE  SYSTEMS  ENGINEERING 
MATURITY  MODEL 

The  full  development  of  the  Systems  Engineering  Matunty 
Model  (SEMM)  requires  that  the  five  instruments  of  the 
CMM,  too,  be  generalized  from  software  engineering  to  sy¬ 
stems  engineering. 

Two  examples  for  the  description  of  the  maturity  levels  1  and 
2  are  shown  in  figures  8  and  9.  These,  too,  are  based  on  the 
SEI  CMM  and  have  been  extrapolated  for  use  with  the  new 
SEMM. 

In  the  description  of  the  key  process  areas  it  is  necessary  to 
incorporate  systems  engineering  aspects  that  ate  absent  from 


software  engineering,  e.  g.  the  development  of  senes  produc¬ 
tion  elements. 

The  adaptation  of  the  SEI  questionnaires  on  the  respondent 
and  the  project  should  be  straightforward. 

However,  the  generalization  of  the  Matunty  Questionnaires 
will  constitute  the  bulk  of  the  remaining  work.  We  understand 
that  a  major  US  company  has  developed  a  tailored  version  of 
one  of  the  SEI  questionnaires  to  assess  its  systems  engineering 
integration  and  test  process.  The  assessment  team  concluded 
that  the  adapted  CMM  and  questionnaire  was  appropnate  for 
this  purpose  (Ref.  10).  Other  organizations  in  the  aerospace 
and  defense  sector  are  also  preceding  in  this  direction. 


Level  1  -  The  Initial  Process 

•  Unstable  environment  lacking  sound  management  practices  - 
Commitments  not  controlled. 

•  Success  rides  on  individual  talent  and  heroic  effort. 

•  Standards  and  practices  often  sacrificed  to  management 
priorities  -  Usually  schedule  and  /  or  cost. 

•  Process  capability  is  unpredictable  -  Schedule,  cost,  and 
performance  targets  are  rarely  met. 

•  Level  of  risk  is  consistently  underestimated. 


Level  2  -  The  Pepeatable  Process 

•  Management  discipline  ensures  that  during  schedule 
crunches  systems  engineenng  practices  are  still  enforced. 

•  Basic  system  management  discipline  is  installed. 

•  Previously  successful  processes  are  repeatable  in  a  stable, 
managed  environment. 

•  Achievable  and  measurable  activitites  are  planned  prior  to 
making  commitments  -  Commitments  are  tracked. 

•  Before  schedule  commitments  are  made,  a  process 
capability  exists  that  enables  the  team  to  meet  schedules 


Figure  8.  Systems  Engineering  Maturity  Level  1 


Figure  9.  Systems  Engineering  Maturity  Level  2 


•  • 
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B««ide(  the  nulehai  picteiited  in  sectioni  7  and  8  the  authors 
have  ptoduced  the  pnliminaiy  charactehzalians  for  level  3  up 
to  S,  but  these  are  omitted  in  this  paper. 

Our  own  experience  and  initial  effort,  the  encouragement  re¬ 
ceived  from  many  sides  and  the  ongoing  work  in  various  or¬ 
ganizations,  including  the  National  Counc^  on  Systems  Engi¬ 
neering  (NCOSE)  indicate  diat  a  suitable  version  of  a  Systems 
Engineering  Maturity  Model  can  indeed  be  developed  on  the 
basis  of  the  software-oriented  Capability  Maturity  Model  of 
SEI. 

Following  the  presentation  and  publication  of  this  paper  we 
welcome  further  comments,  especially  from  the  software  en¬ 
gineering  community,  to  promote  the  complete  development 
and  finalization  of  the  evoNing  SEMM. 

9,  CONCLUSIONS 

In  the  initial  section  of  this  paper  we  stated  two  major  goals: 

1 )  to  provide  a  framework  for  assessing  systems  engineering 
processes  and  to  identify  critical  process  areas 

2)  to  stimulate  further  work  m  the  development  and  applica¬ 
tion  of  methodologies  to  assess  and  improve  the  practice  of 
systems  engineering. 

It  is  appropriate  that  our  conclusions  be  related  to  these  goals. 

As  to  the  fust  goal,  we  have  approached  it  by  developing  an 
extension  of  the  SEI  software  engineering  framewoik.  The  re¬ 
sulting  systems  engineering  framewoik  reflects  -  besides  the 
sirenghts  -  also  the  weaknesses  of  the  CMM,  it  is  still  incom¬ 
plete,  and  we  have  treated  the  structural  problems  with  insuf- 
fKient  depth.  But  even  with  these  shortcomings  we  believe 
that  the  framework  provides  a  first  basis  for  systems  enginee¬ 
ring  process  assessmenL  Further,  the  key  process  areas  discus¬ 
sed  ui  section  7  and  summarized  in  rigure  7  address  a  number 
of  critical  problem  fields  of  systems  engineering.  We  are 
confident  that  improvements  in  these  areas  will  indeed  raise 
customer  and  producer  satisfaction  and  also  reduce  the  deve¬ 
lopment  risk  of  products  and  services. 

As  to  the  second  of  our  goals,  we  have  indicated  in  section  8 
those  parts  of  the  framework  that  are  still  incomplete  or  mis¬ 
sing,  leaving  opportunities  for  complementary  work  in  this 
important  area.  During  our  research  activities  we  became 
aware  of  a  growing  consensus  among  buyers  and  selleis  of  sy¬ 
stems  engineering  products  and  services  that  sound  methodo¬ 
logies  to  assess  systems  engineering  maturity  are  actually  nee¬ 
ded  and  would  be  widely  welcome.  Given  this  need  we  would 
like  to  encourage  interested  collegues  in  joining  the  effort  to 
finish  a  complete  Systems  Engineering  Maturity  Model. 

In  closing  we  wish  to  thank  the  AGARD  Avionics  Panel  for 
the  opportunity  to  present  the  results  of  our  current  work. 
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Discussion 


Questioo  W.  ROYCE 

Will  die  deflnitioo  of  a  systems-orienled  capability  maturity  model  force  a  change  in  the  current  SEI  model  for  software 
only? 

Reply 

This  question  raises  a  good  point  Looking  beyond  our  present  work.  I  would  not  exclude  the  possibility  that  the  authors 
of  the  CMM  will  review  tbe^  model  with  respect  to  systems  engineering.  One  mea  that  comes  to  my  mind  would  be  to 
inootponte  in  the  CMM  the  interfaces  of  the  software  engineering  process  to  the  systems  engineering  process. 


Fabrizio  SANDRELLI 
(SW  Quality  Responsible) 
ALENIA  DAAS 
Via  dei  Castelli  Ronumi,2 
00040  Pomezia  (Rome)  ITALY 


Summary 

In  the  technologically  advanced  field  of  avionics, 
quality  is  today  lequired  both  by  the  market  and  the 
engineers.  This  means  that  quality  is  not  only  a  goal 
to  reach  new  costumers,  but  is  a  different  way  of 
working  which  aims  to  reach  a  higher  and  more 
satisfKtory  working  environment. 

The  attention  has  been  focused  on  the  technical 
information  produced  during  the  development  of  the 
project  and  its  diffusion  through  the  technical  and 
managerial  environment.  The  goal  is  the  improving 
of  the  quality  of  the  whole  development  process 
where  the  quality  of  the  final  products  comes  as  a 
consequence. 

This  paper  describes  a  methodology  experienced  in 
the  last  few  years  in  ALENIA  (Pomezia  Plant)  to 
plan,  achieve  and  manage  a  more  flexible  and 
advanced  way  of  working,  through  the  strong 
involvement  of  all  who  contribute  to  the  realization 
of  the  product. 

Attention  has  been  focused  both  on  the 

organizational  aspect  of  the  project  and  the  product 
configuration.  Those  two  aspects  are  seif  related  and 
bring  to  a  correct  management  of  the  project. 

List  of  Symbob 

Cl  Configuration  Item 

CPJ  Company  Project 

CSCl  Computer  Software  Configuration 

Item 

HWCI  Hardware  Configuration  Item 


Informatioa  Structuring 

The  capability  to  maintain  software  projects  and  to 
guarantee  their  quality,  is  based  on  the  way  the 
internal  communication  of  the  technical  and 
technical-managerial  information  is  managed.  All  the 
information  about  process  and  product  has  been 
structured  and  the  communication  process  organized 
and  automated. 

Task  of  every  project  is  to  produce  the  technical 
documentation  that  will  allow  the  building  of  the 
product  (be  the  product  a  software  code  as  well  as  a 
physical  device).  So,  from  the  project  development 
point  of  view,  the  technical  documentation  is  the 
product.  A  correct  quality  and  configuration  control 
of  the  technical  documentation  allows  then  to  know 
exactly  the  status,  the  story  and  the  evolution  of  the 
project,  in  order  to  achieve  a  much  better  quality  of 
it. 

A  conqilex  Project,  during  its  life-cycle  phases,  is 
hierarchically  decomposed,  following  a  top-down 
methodology,  into  elementary  projects,  each  of  ones 
is  finalized  to  the  development  of  one  or  more 
configuration  items. 

At  high  level  the  design  process  is  independent  from 
the  technology  and  is  represented  by  a  generic 
Configuration  Item  (Cl).  Only  at  the  lower  levels  it 
differmtiates  in  hardware  and  software  components, 
each  of  ones  is  typically  finalised  to  the  development 
of  one  or  more  Cls.  The  Cls  whose  ftmctionalities 
have  been  exactly  defined  are  always  referred  to  as 
HWCI  if  they  will  be  developed  as  hardware  and 
CSCl  if  they  will  be  developed  as  software. 
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In  this  paper,  moatly  interested  to  software,  a  CSCl 
is  considered  as  an  aggregation  of  software  that:  has 
been  requested  to  be  a  CSCI  by  the  purchaser,  needs 
a  separate  developaieiit,  my  be  considered  by  itself, 
has  a  high  level  of  complexity  and  a  high  probability 
of  evolution,  is  general-purpose  and  may  be  used  in 
more  applications,  satisfies  an  end  use  function,  is 
designated  for  separate  configuration  management 
and  has  a  direct  impact  on  the  budget. 

The  software  project/product  life-cycle  is  managed 
at  CSCI  level:  the  technical  documentation  is 
produced  and  the  planned  quality  activities  Previews, 
acceptance  tests  and  audits)  are  performed  for  each 
CSCI. 

Through  a  set  of  project/product  relationships  a 
hierarchical  structure  of  activities  is  obtained  (Work 
Breakdown  Structure),  whose  terminal  elements  are 
the  configuration  items  related  to  the  project. 

In  fig.  1  there  is  a  typical  hierarchical  decomposition 
of  a  complex  project  (CPJ)  into  elementary  projects 
(PJs);  each  CPJ  structure  starts  horizontally  from  its 
founder  and  lasts  with  the  development  of  the  related 
items. 

In  this  structure,  every  CPJ  is  organised  in  'Project 
Activities'  (PJA)  following  the  'activity  based 
management'  techniques.  Each  PJA  is  composed  of 
PJs,  each  of  ones  is  finalised  to  the  development  of 


one  or  more  Configuration  Items.  Every  project  is 
planned  to  be  articulated  into  phases  with  a  standard 
production  of  technical  and  managerial 
documentation  and  information  about 

responsibilities,  goals  and  progresses  of  times,  costs 
and  results. 

The  structure  which  binds  up  the  PJs  and  the  relative 
managerial  documentation  to  the  configuration  items 
is  called  'Project  Tree'. 

Task  of  the  CPJ  leader  is  to  guarantee  the  technical 
and  economical  control  of  the  CPJ  itself.  This  is 
obtained  assigning  one  responsible  and  a  budget  to 
every  PJA  that  belong  to  the  CPJ.  Every  PJA  reports 
the  activity  work  packages,  including  costs  (hours, 
technical  equipment,  general  expenses,  suppliers  and 
so  on)  and  development  times. 

At  the  end  of  the  estimating  phase,  such  activities  are 
structured  in  a  hierarchical  tree  and  constitute  the 
Work  Breakdown  Structure  of  a  complex  project. 
Both  goals  and  the  tasks  achieved  are  associated  to 
each  PJA.  The  responsible  for  the  activity  is  then  able 
to  know  the  matching  or  the  deviations  against  the 
goals. 

At  the  end  of  the  development  of  a  CPJ,  the  set  of 
PJs  activated  for  any  specific  development,  has 
structured  in  a  hierarchical  relationship  all  the  CIs, 
CSCIs  and  HWCIs  that  compose  the  whole  product. 


Tr«« 


t% 


Tr*» 


•  PrajMI  Aottvily 


fig.  1  -  Configuration  Tree 
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•ad  the  tocliBical  dnrMiWHitirton  has  bwa  deveioped 
to  the  most  detailed  compoaeats. 

The  stnictiife  composed  of  the  whole  of  the  CIs, 
CSCIs  aad  HWCIs  sad  the  techaical  dncumeatatioa 
is  called  ‘Product  Tree*. 

The  set  of  the  software  coafiguration  items  is 
structured  in  a  sub-set  of  the  Product  Tree  called 
’ Software  Tree*. 

At  the  beginning  of  a  software  project,  the  software 
project  leader  and  the  software  configuratioa 
controller  create  in  the  Central  Data  Base  a  Software 
Tree  for  it.  In  the  Software  Tree,  a  software 
project/product  is  assigned  a  CSCI  identified  by  a 
code.  This  CSCI  is  decomposed  with  the  top-down 
methodology,  in  lower  level  CSCIs  with  a  higher 
degree  of  detail,  uhich  are  also  identified  by  an 
univocal  code. 

If,  for  example,  an  operative  system  is  a  ‘special 
purpose*  one,  it  is  assigned  a  low  level  CSCI  which 
hierarchically  belongs  to  the  CSCI  of  the  software 
project  into  which  the  operative  system  is  developed. 

On  the  other  hand,  ifthe  operative  system  isa  ‘general 
purpose*  one,  it  is  assigned  one  dedicated  CSCI,  but 
it  can  be  used  in  any  software  project.  This  can  be 
done  because  the  software  may  be  imported  from  one 
CSCI  to  any  other  one.  In  the  case  of  the  exanqrle, 
the  software  files  that  compose  the  general  purpose 
operative  system  may  be  imported,  for  being  used,  in 
any  project  that  needs  them. 

Any  low  level  CSCI  is  articulated  into  non-configured 
components  (CSC),  each  of  ones  is  also  assigned  a 
code.  Each  CSC  is  an  aggregation  of  Computer 
Software  Units  (CSU),  that  is:  files, as  shown  in  fig.2. 


CSU  CSU  CSU  (filas) 


Associated  lo  each  CSCI  is  the  technical 
documentation  which  constitutes  the  outputs  of  the 
software  product  life  cycle.  When  such  documents  are 
actually  placed  under  formal  configuration  control, 
they  have  already  been  given  all  the  authoriaatioas 
and  successfully  passed  all  the  reviews. 

This  way  of  structuring  allows  working  in  parallel  on 
the  same  software  project.  If,  for  example,  the 
product  will  be  a  computer  board  with  a 
microprocessor  on  it,  the  software  project  will  be 
composed  of  the  basic  software  for  driving  the 
microprocessor  and  the  application  software  which 
drives  the  application.  Assigning  one  CSCI  to  the 
basic  software  and  another  CSCI  to  the  application 
software,  allows  two  different  software  teams  to  start 
working  in  parallel,  having  defined  only  the  interfaces 
between  the  two  CSCIs.  When  the  basic  software  will 
be  requested,  for  example  for  loading  it  into  the 
microprocessor,  the  software  stored  under  the  basic 
software  CSCI  will  be  imported  into  the  CSCI  which 
needs  it  at  the  requested  release,  also  if  the  basic 
software  has  evolved  in  the  meanwhile  to  subsequent 
releases. 

This  concept  of  linking  different  CSCIs  or,  at  higher 
level,  different  CIs,  is  essential  for  managing  large 
scale  projects  which  involve  subcontractors,  as  it 
usually  happens.  It  is  of  fundamental  importance  to 
maiuge  the  subcontractors  technical  documentation 
in  the  same  way  as  the  internal  one,  in  order  to  have 
a  real  estimate  of  the  whole  project  progressing.  For 
this  reason,  all  the  documentation  form  the 
subcontractors  is  also  placed  under  configuration 
control. 

The  technical  documentation  is  the  link  between  tbe 
PJA  and  the  software  product  (as  shown  in  fig. 3). At 
any  time  of  the  software  project,  looking  at  the 
archived  documentation,  it  is  possible  to  know  what 
has  been  produced  by  the  Company  and  by  the 
subcontractors,  which  means  that  it  is  possible  to 
'measure*  the  progress  status  of  the  project.  There 
are  two  indicators  that  allow  a  correct  management 
of  the  activity:  the  quantity  of  documentation 
produced  against  the  estimated  and  the  degree  of 
confidence  of  this  documentation.  The  confidence  is 
guaranteed  by  the  quality  activity,  because  every 
document  may  be  stored  into  the  Data  Base  only  if 


fig.2  -  Software  Breakdown  Structure 
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auUKmaed  by  the  quality  reapoaaibie  after  the 
appropriate  leviewa.  The  ipiality  head  alao  mooilors 
the  progieaa  of  the  project  in  order  to  point  out  every 
delay  in  the  documentation  productiao  and  take  the 
appropriate  actions. 
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lig.3  -  Activity/Product  Relationship 

Any  problem  in  the  developed  software  or  in  the 
documentation  is  managed  through  a  Problem 
Reporting  and  Corrective  Action  system.  If  there  is 
a  need  for  a  change,  a  software  item  under 
configuration  control  may  be  updated  after  careful 
evaluation  and  by  authority  received  from  the 
provided  beads,  following  the  change  flow  described 
in  fig.4. 


The  instigators  of  software  changes  may  be  internal 
or  eatemal  to  the  Company;  they  detail  the  reasons 
for  change  requests,  using  standard  or  non  standard 
forms. 

Automatioii 

It  has  been  accepted  that  any  formal  procedure  helps 
in  achieving  the  goals.  The  project  structures  are 
physically  implemented  into  an  automated 
Informatitm  System  which  gives  the  measure  of  the 
progress  of  the  project  through  the  actual  status  of 
the  documentation  stored. 

The  Information  System  is  based  on  a  Central  Data 
Base,  into  which  it  stores  the  information  that  come 
from  the  progress  of  the  project  activities  and  from 
which  it  takes  all  the  data  about  plamiing  and  costs. 
From  a  conceptual  point  of  view.all  the  informatioo 
are  spread  when  formally  stored  into  the  Central  Data 
Base,  considering  that  the  Central  Data  Base  can  be 
accessed  through  a  network  of  local  workstations  by 
any  area  of  the  foctory. 

The  use  of  the  Information  System  involves  the  use 
of  informal  procedures  that  have  been  standardised 
and  automated.  This  is  a  basic  requirement  for 
producing  data  in  an  orderly  and  controlled  way  and 
to  have  them  available  in  time.  These  procedures 
allow  to  aggregate  all  the  data  about  responsibilities. 
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fig.4  -  Changes  Management 
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pUnned  documenUtion  and  scheduling  to  the 
different  (eveU  into  which  a  complex  project  is 
articulated. 

The  use  of  the  Informatioa  System  allows  to: 

•  rationalize  all  the  technical  doctunentatioo  inallthe 
phases  of  the  project  life-cycle,trace  the  anomalous 
situations  and  manage  the  product  configuration; 

-  enhance  the  exchange  of  technical  and  managerial 
information  between  different  areas  and  the 
availability  of  infoiioation  since  the  beginning  of 
the  project; 

-  have  a  constant  and  capillary  tracking  on  the  project 
activities,  in  order  to  activate  a  real  time  corrective 
action  procedure,  if  necessary. 

The  Information  System  maintains  and  guarantees 
the  configuration  integrity  (organization,  control, 
status  accounting)  relatively  to  the  technical  product 
documentation  of  the  configuration  hardware  and 
software  items  (HWCI  and  CSCI)  and  to  the 
technical  data  of  interest  in  the  development,  like 
information  structures,  data  base  architecture  etc. .  It 
also  allows  to: 

-  manage  accurately  and  in  a  standard  way  the 
hardware  and  software  product  and  project 
documentation  (both  electronic  and  on  paper); 


-  parallelin  the  project  activities  in  a  controlled  way; 

-  manage  hardware  and  software  interactions. 

The  Information  System  provides  the  tools  necessary 
to  a  good  marugement  of  the  product  development. 

During  the  development  of  the  project,  the 
Information  System  gives  the  global  situation  of  the 
progress  of  the  project  itself  through  a  the  set  of 
reports,  for  example  the  ‘Current  ’  and  ‘Historical* 
Status  Reports,  the  ‘Where  Used*  and  the  ‘Review 
and  Audits*  ones. 

:  he  use  of  these  reports  allo'vs  to  anticipate  as  much 
as  possible  the  spread  of  the  information  necessary 
to  the  development  of  the  whole  project,  in  sucl 
way  to  'linage  all  the  related  Activities  as  mui.i 
efficieni.,  as  possible. 

Data  from  the  Information  System  are  presented  in 
tabular  form*:,  the  most  used  of  which  is  the 
Configuration  List.  An  example  is  in  fig.S  where  a 
software  tree  is  reported. 

Through  the  Configuration  List  all  the  changes  to  the 
configured  items  are  managed. 

When  a  change  is  needed  and  agreed  m  the  software 
already  developed,  the  CSCI  is  given  the  status  of 
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'duBging  in  progress*.  This  status  results  in  the 
Configunuioa  List,  because  the  release  number  ol' 
the  affected  CSCl  isprinted  between  *()'.Who  makes 
a  printout  of  the  report  knows  that  the  software  is 
going  to  be  changed,  the  foreseen  date  when  the 
changes  will  be  applied  and  who  is  the  responsible 
for  Ois  action. 

As  a  demnnstration,  it  may  be  considered  that  often 
a  software  change  has  an  immediate  impact  on  the 
Production  Department.  The  Production  Head 
knows,  from  the  Configuration  List,  that  the  software 
actually  in  use  is  going  to  be  changed,  he  must 
immediately  consider  whether  continuing  to  use  the 
old  software  or  suspending  the  production,  waiting 
for  the  next  software  release.  From  the  Configuration 
List  be  takes  all  the  uiformation  needed  to  support 
his  decision. 

Such  a  way  of  proceeding  favours  the  diffusion  of  the 
uiformation  horizontally  through  the  company, 
reducing  to  the  minimum  level  the  necessity  of 
organizing  work  progress  meetings  and  reducing  a  lot 
the  time  between  the  moment  when  the  critical  event 
occurs  and  when  the  new  situation  is  faced. 


Coadusinnn 

This  way  of  working  allows  to  create  information  in 
a  standard  and  accurate  way  and  to  speed  up  as  much 
as  possible  the  information  diffusion  and  updating;  it 
favours  the  people  who  are  involved  in  the  project  to 
take  always  more  pan  in  it,  promotes  team-works, 
enhancing  the  responsibilities  capillarily  down  to  the 
lowest  levels  of  the  developing  chain. 

The  timeliness  by  which  mfbnnation  is  available, 
allows  the  parallel  start  of  developing  phases 
otherwise  sequential,  with  a  cascade  process  which 
anticipates  a  lot  the  end  of  a  project,  compared  with 
the  traditional  developments. 

Such  a  dynamic  and  effective  way  of  managing  the 
project,  makes  anomalies  and  errors  more  evident  so 
that  they  can  be  solved  as  early  as  possible.  The  final 
product  is  mtnnsically  improved  from  the  quality 
point  of  view.because  the  intervention  is  spread  along 
the  whole  developing  process  with  the  important 
contnbution  of  all  the  involved  departments  and,  at 
the  same  time,  costs  and  developing  times  are 
dramatically  reduced. 
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1.  SUMMARY 

Under  the  sponsorship  of  the  Naval  Air  Warfare  Center 
Warminster,  Pa.,  U.S.A.  an  initiative  was  undertaken  to 
establish  a  de  facto  project  standard  for  a  "software 
product"  for  Mission  Critical  Computer  Resources 
(MCCR).  This  effort  is  an  outgrowth  of  a  risk  reduction 
approach  to  improving  the  MCCR  software  development 
and  acquisition  process  based  on  W.  Edward  Deming’s 
renowned  quality  principles. 

While  defming  a  "software  product"  might  appear  to  be 
rudimentary,  the  hypothesis  is  put  forth  that  the  software 
product  itself,  which  has  been  inexplicably  neglected  by 
the  software  engineering  community,  is  the  key  element 
and  focal  point  for  understanding  and  improving  the 
software  development  and  acquisition  process. 

This  paper  describes  the  model  of  a  "software  product" 
that  was  developed  to  1)  promote  uniform  software 
product  nomeitclature.  2)  serve  as  a  reference  point  for 
software  process  improvement,  3)  provide  a  basis  for 
developing  a  more  cost-effective  software  documentation 
standard,  and  4)  provide  a  more  rigorous  means  of 
specifying  software  deliverables  for  MCCR.  Other 
potential  benefits  of  the  software  product  model  include 
providing  a  convenient  and  effective  means  to  1)  uniformly 
baseline  diverse  software  products,  2)  establish  software 
configuration  management  and  control,  3)  ensure  the 
capture  of  all  software  components  required  for 
regeneration,  4)  provide  a  natural  mechanism  for  the 
collection  of  software  product  metrics,  and  5)  facilitate 
the  on-line  sharing  and  reuse  of  software  programs, 
documents,  and  data.  The  software  product  model  that 
has  been  developed  is  referred  to  as  STORE,  which  stands 
for  Software  Product  OReanization  and  Enumeration.  The 
STORE  is  a  graphical,  hierarchical  model  that  provides  a 
complete  and  logical  decomposition  and  description  of  a 
software  product  for  MCCR.  The  productized  version  of 
STORE  will  be  suitaUe  for  the  uniform  specification, 
procurement,  and  conflguration  management  of  software 
products  for  software  life  cycle  support  The  ultimate 
goal  is  the  evolutionary  development  of  a  full-blown 
STORE  that  will  be  a  complete  Spftware  Efoduct  Open 
gepository^nvironment 

2.  THE  SOFTWARE  EXPLOSION 

The  defense  and  aerospace  industry  is  experiencing  a 
softwareexplosionasar^tofthewidespreadavailability 
of  low-cost  high  performance  computers.  This  software 


explosion  has  manifested  itself  in  various  forms:  1)  a 
diversity  of  computer  system  architectures,  operating 
systems,  programming  languages,  software  engineering 
environments,  and  communication  networks,  2)  a 
proliferation  of  Computer  Aided  Software  Engineering 
(CASE)  toc^  and  software  application  domains,  and  3) 
a  wide  spectrum  of  development  methodologies  and 
software  innovations,  such  as  ‘object-oriented  design’ 
and  ‘graphical  user  interfaces‘ ,  to  meet  the  need  for  more 
capable  and  user-frieiully  software.  However,  despite  all 
the  new  technology  developments  in  hardware  and 
software,  the  demand  for  software  is  rapidly  outstripping 
our  ability  to  produce  it.  And  the  elusive  goals  of 
producing  error-free  software,  on  schedule,  and  within 
budget,  remain  elusive  and  formidable. 

3.  MEETING  THE  SOFTWARE  CHALLENGE 
What  will  it  take  to  meet  the  software  challenge?  First,  it 
will  take  an  abundance  of  profound  knowledge.  The 
starting  point  is  recognizing  that . . . 

Software  Development  is  a  highly 
creative,  arduous  and  abstract,  labor-intensive  process 
of great  complexity.  The  process  itself is  characterized  by 
successive  and  highly  iterative  stages  -  each  of  which 
constitmesaradical  traruformabon  -  that  together  produce 
an  invisible  end-product.  The  outputs  of  the  individual 
stages  are  one  or  more  descriptive  documents  and/or 
intermediate  software  elements  (either  of  which  may,  or 
may  not,  signify  completion).  The  stages  typically  progress 
from  asetpfspecifiedneedsandconstrainlsisi  acomputer 
system  architecture  [p  a  set  of  software  requirements  ip 
a  software  design  (p  software  code  units  (p  a  set  of 
executable  elements  that  implement  a  particular 
instantiation  of  the  desired  functional  capability  which 
(hopefully)  meets  the  specified  needs  within  the  given 
constraints. 

Second,  it  will  take  perseverance  and  commiunent  to 
bring  about  the  necessary  transformations  in  our  current 
policies,  practices,  and  engineering  culture  that 
CtaditionaUy  have  been  hardware-oriented. 

The  comprehensive  definition  of  software  development 
that  is  given  above  serves  to  provide  needed  insight  into 
the  scope  and  complexity  of  the  software  developtnent 
process  that  we  must  master,  or  that  will  continue  to 
master  us.  Clearly,  there  is  no 'silver  builet‘  solution  to  the 
software  problem  on  the  horizon.  And  perhaps,  as  the 
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dennilion  above  impties,  a  unifonn,  foraiai  discipline 
solutiofi  may  not  be  achievable  in  (he  classical  engineering 
sense.  There  is.  however,  the  promise  of  steady,  if 
unspectacular  progress  [I). 

4.  IMPROVING  THE  CURRENT  STATE-OF- 
PRACTICE  IN  SOFTWARE 

With  the  astronomical  growth  in  software,  it  is  widely 
recognized  that  there  is  an  ever  increasing  need  for 
uniform,  disciplined  approaches  to  advance  the  cause  of 
software  from  an  art  form  to  an  engineering  science.  This 
applies  not  only  to  the  software  development  process,  but 
to  (he  entire  software  life  cycle,  which  encompasses 
everything  from  major  software  enhancements  and 
upgrades  to  corrective,  perfective,  and  adaptive  software 
maintenance.  Consistent  with  W.  Edward  Deming’s 
renown  quality  principles  [2],  an  effective  strategy  for 
realizing  steady  software  progress  is  toconcentrate  on  the 
singular  goal  of  improving  quality  (in  areas  of  greatest 
identified  risk)  using  a  disciplined,  process-oriented 
approach.  This  approach  is  believed  to  offer  the  most 
potential  for  coping  with  the  growing  diversity  and 
complexity  of  software  and  for  enhancing  our  ability  to 
produce  a  quality  software  product  in  a  timely,  efficient, 
and  cost-effective  manner.  The  Capability  Maturity 
Model  (CMM)  for  software  process  improvement,  which 
was  developed  by  the  Software  Engineering  Institute 
(SEI),  is  a  well  recognized  example  of  such  a  disciplined, 
process-oriented  approach  to  software  risk  reduction  and 
quality  improvement  [31. 

5,  THE  MISSING  ELEMENT:  "THE  SOFTWARE 
PRODUCT" 

Considerable  emphasis  has  been  placed  on  software 
process  improvement  as  an  effective  means  of  improving 
software  quality  and  productivity.  Clearly,  this  has 
recognized  merit.  However,  if  software  process 
improvements  are  to  be  properly  directed  and  focused,  a 
parallel  effort  is  needed  to  explicitly  define  what  constitutes 
a  properly  constructed  and  quality  "software  product" 
(i.e.,  the  output  of  the  process).  While  defining  a  "software 
product"  might  appear  to  be  rudimentary,  the  aigument  is 
put  forth  that  the  software  product,  which  has  been 
inexplicably  neglected  by  the  software  engineering 
community,  is  the  key  element,  and,  in  fact,  (he  focal  point 
for  understanding  and  improving  the  software  engineering 
process.  With  the  growing  complexity  of  software,  the 
diversity  of  application  domains,  and  the  inherently 
abstruse  nature  of  software,  there  is  a  pressing  need  to 
establish  a  common  software  structure  and  unambiguous 
nomenclature.  Thisisconsideredessentialforidentifying, 
describing,  and  communicating  the  salient  characteristics 
and  attributes  of  all  the  components  that  makeupacomplete 
"software  product".  One  value  in  creating  an  engineering 
model  of  the  "software  product"  is  its  ability  to  serve  as  a 
uniform  means  of  gaining  visibility  and  insight  into  the 
complexities  and  interdependencies  of  the  software 
devek^xnent  process.  And  how  can  one  embark  on 
improving  aixl  optimizing  the  software  acquisition  process 
(or  the  software  development  process)  without  first 


defining  its  ouqmt  (i.e.,  the  software  product)? 

6.  THE  SOFTWARE  PRODUCT  -  A  COMMON 
FOCAL  POINT 

The  "software  product"  provides  a  common  focal  point 
across  the  acquisition  process.  Figure  1  depicts  the  basic 
software  acquisition  process  that  typifies  how  software  is 
procured  for  Mission  Critical  Computer  Resources 
(MCCR).  The  process  comprises  three  major  stages  or 
phases:  1)  the  specification  and  procurement  phase,  2) 
the  contractual  software  development  phase,  and  3)  the 
life  cycle  support  phase.  As  indicated  on  the  diagram,  a 
key  element  in  the  process  is  the  deliverable  software 
product  Acomprehensive  understanding  of  thesoftware 
product  can  serve  as  a  focal  point  for  improving  the 
software  development  process,  planning  for  software  life 
cycle  support,  conveniently  specifying  software 
deliverables,  defining  software  documentaikm  needs, 
establishing  sound  software  configuration  management 
practices,  or  collecting  software  product  metrics.  A 
"software  product"  model  is  multi-faceted  and  can  be 
viewed  ftom  many  different  perspectives  as  illustrated  by 
the  following  descriptions: 

1)  a  common,  intuitive,  software  template, 

2) ageneric  specification  for  the  software  product 
deliverables, 

3)  a  hierarchical  decomposition  of  the  software 
and  its  documentation, 

4)  a  standard  engineering  reference  model  with 
uniform  nomenclature. 

5) an  interface  standard  for  software  deliverables, 

6)  a  generic  framework  suitable  for  dcfming  a 
repository  for  MCCR  software. 

7)  a  means  to  facilitate  sharing  and  reuse  of 
programs,  documents,  and  data, 

8)  a  rigorous  model  for  the  development  of  a 
software  documentation  standard,  and 

9)  a  training  aid  for  educating  management/ 
project  personnel. 

In  actuality,  the  concept  of  a  generic  model  for  a  "software 
product"  embraces  all  of  these  ideas.  As  the  list  above 
suggests,  there  appear  to  be  many  practical  applications 
for  a  "software  product"  model. 

7,  A  CUSTOMER  CENTERED,  RISK  REDUCTION 
AND  QUALITY  IMPROVEMENT  INITIATIVE 
This  paper  describes  an  initiative  to  develop  a 
comprehensive  model  of  a  "software  product"  intended 
for  MCCR.  The  initiative  embraces  a  disciplined, 
customer-centered,  process-oriented  approach  toward 
improving  the  current  ;iate-of-practice  in  software 
engineering.  The  potenbal  benefits  and  the  engineering 
rigor  a  model  can  provide  were  a  significant  impetus  for 
undertaking  the  development  of  the  "software  product" 
model. 

Fcm’  the  software  customer  who  buys  a  Commercial  Off- 
The-Shelf  (COTS)  software  tool,  the  software  product 
can  be  characterized  as  a  floppy  disk  (that  contains  the 
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Figure  1.  A  Strategic  Framework:  The  Software  Acquisition  Process 


software  application)  and  a  set  of  user  manuals  or  reference 
documents.  The  customer,  in  this  case,  does  not  have  a 
need  for  any  thing  more  (in  the  way  of  a  software  product), 
and  depends  on  the  original  vendor  to  support  the  product 
and  periodically  provide  new  releases  to  :x)rrect  software 
"bugs”,  improve  performance,  and  provide  new  and 
enhancedcapabilities.  Thecustomer'scotKemsaremainly 
directed  towards  buying  the  most  capability  for  the  dollar 
that  will  meet  his/her  particular  needs  in  their  domain  of 
interest. 

In  marked  contrast,  the  customer  who  acquires  software 
for  MCCR  requires  a  very  different  kind  of  software 
product  because  of  the  need  to  provide  indigenous  life 
cycle  support  for  as  long  as  the  software  product  is 
operationally  deployed.  Inthiscase.thesoftwarecustomer 
wants  assurance  that  his/her  activity  (or  company)  will  be 
able  to  lake  delivery  of  the  software  product  and  ensure  a 
smooth  transition  to  the  life  cycle  support  phase.  This 
translates  into  a  stringent  set  of  requirements  (in  the 
procurement  phase)  to  ensure  obtaining  a  complete  set  of 
software  deliverables,  up-to-date  descriptive  software 
documents,  information  for  regenerating  the  software 
end-product,  and  a  clear  understanding  of  the  software 
product's  structure,  composition,  dependencies,  and 
interrelationships.  The  high  skill  level  and  discipline 
requited  to  properly  specify  these  requirements  and 
understand  all  of  the  intricacies  of  a  software  product  for 
MCCR  were  a  major  impetus  behind  this  initiative  to 
develop  a  comprehensive  model  of  a  software  product. 

The  software  product  initiative  addresses  an  area  of 
significant  risk  that  relates  directly  to  a  demonstrable 
customer  need.  As  such,  it  represents  a  quality 
improvement  that  promises  a  significant  return  on 
investment.  This  initiative  is  believed  to  have  significant 
potential  for  improving  the  current  state-of-practice  in 
software  because  the  software  product  defmition  will 
provide  valuable  insight  for  the  implementation  of 


improvements  to  the  processes  associated  with  each  of 
the  three  phases  of  the  acquisition  process. 

8.  THE  SOFTWARE  PRODUCT  -  MORE  THAN  A 
SET  OF  DOCUMENTS 

A  common  practice  in  evaluating  or  monitoring  the 
software  development  process,  or  judging  the  efficacy  of 
a  software  product,  or  conducting  a  critical  software 
review  is  to  treat  the  software  product  as  if  it  were 
synonymous  with  the  associated  setof  descriptive  software 
documents.  This  approach  is  flawed  because  there  is  no 
intrinsic  mechanism  for  insuring  that  the  descriptive 
software  documents  and  the  various  elements  that  comprise 
the  actual  "as-built"  software  are  truly  reflective  of  each 
other.  Software,  therefore,  is  more  than  a  set  of  descriptive 
documents  or  specifications  -  it  is  the  sum  total  of  all  the 
elements  that  constitute  a  software  product.  These 
elements  include  the  actual  application  programs  and  run¬ 
time  software,  program  libraries,  operating  system 
software,  software  regeneration  elements,  software 
development  artifacts,  as  well  as  the  end-product  and  its 
comprehensive  set  of  descriptive  software  documents.  In 
essence,  the  software  product  encompasses  all  the 
intermediate  products  and  by-products  of  each  of  the 
iterative  stages  described  in  the  deflnition  of  software 
development 

9.  THE  QUALITY  PAYOFF:  HUGE  COST 
SAVINGS 

The  potential  cost  savings  that  can  be  achieved  by  adopting 
a  common  model  to  understand,  describe,  specify,  and 
procure  software  for  MCCR  are  believed  to  be  enormous. 
Today’s  major  software  standards  do  not  adequately 
address  the  full  extent  of  required  deliverables.  For 
example,  they  do  not  explicitly  qiecify  the  software 
elements  needed  for  software  regeneration  or  the  software 
development  artifacts  needed  for  efficient  and  cost- 
effective  lifecycle  support.  Consequently,  every  software 
project  must  fend  for  itself  to  obtain  the  extraordinary 
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expertise  ll)atisre<|iiiied  to  adequately  specify  the  software 
product  and  its  associated  deliverables.  The  problem  is 
that  most  projects  do  not  have  suffic^t  time  or  the 
expertise  to  do  this  properly.  In  fact,  the  commonly 
accepted  practice  of  tailoring  software  standards  and  their 
deliverables  for  project-specific  use  often  compounds  the 
problem.  Consequently.thedeliveredsoftwareivoduciis 
rarely  complete.  Missing  documents,  missing  source 
code.missing  system  generation  diiectives.and  an  inability 
to  regenerate  the  software  are  typical  problems  that  may 
take  months  to  years  to  rectify.  The  bottom  line  is  that  the 
typical  project  does  not  get  delivery  of  the  software 
elements  and  technical  information  necessary  to  load, 
install,  operate,  regenerate,  maintain,  and  re-engineer  the 
software.  Even  small  projects  (i.e.,  on  the  order  of 20,000 
Delivered  Source  Instructions)  can  expend  1  -2  man-years 
of  effort  in  preparing  for  lifecycle  support  of  the  software, 
and  large  software  projects  (on  the  order  of  100.(X)0 
Delivered  Source  Instructions)  can  expend  many  dmes 
this  amount  of  effort  And  in  many  instances,  additional 
funds  are  required  to  procure  software  tools,  software 
licenses,  or  even  computer  systems  due  to  unforeseen 
events  stemming  from  inadequate  specifications  and  other 
technical  considerations  relevant  to  life  cycle  support. 
Occasionally,  the  problems  escalate  and  litigation  is 
necessary  to  resolve  discrepancies  and  misunderstandings 
or  differences  of  interpretation  concerning  the  contractual 
software  deliverables.  Multiply  this  avoidable  loss  of 
time,  man-power,  and  money  across  every  software¬ 
intensive  project  and  the  amount  becomes  staggering.  It 
is  the  summation  of  all  these  incurred  costs  across  a  very 
large  number  of  projects  that  is  projected  to  be  enormous 
•  in  excess  of  hundreds  of  millions  of  dollars  or  more. 
Work  is  required  to  precisely  quantify  and  document  the 
quality-induced  cost  savings  for  a  pilot  project(s). 
However,  based  on  years  of  experience  working  on 
software-intensive  projects,  the  potential  cost  savings 
and  return  on  invesunent  are  considered  to  be  very 
substantial  and  warrant  refming  the  model  and  possibly 
pursuing  its  adoption  as  a  standard  for  MCCR. 

10.  REVERSE  ENGINEERING:  A  SYMPTOM  OF 
THE  PROBLEM 

In  the  current  software  literature  there  is  a  great  deal  of 
emphasis  on  re-engineering  and  reverse  engineering.  Re¬ 
engineering  can  be  described  as  the  middle  ground  between 
repair  and  replacement  where  the  re-engineering  is 
intended  to  revitalize  an  existing  software  system  by 
making  substantial  changes  in  terms  of  adding  new 
capabilities,  adapting  to  new  requirements,  and/or 
improving  supportability.  It  is  understood  that  a  well 
documented  baseline  is  a  prerequisite  for  re-engineering 
an  existing  system.  However,  the  majority  of  operational 
systems  in  the  field  are  typically  undocumented,  any 
speciflcations  that  do  exist  are  out  of  date,  and  in  many 
instances  the  program  structure  is  virtually  unknown,  the 
code  is  unreadable,  and  the  actual  algorithms  and  software 
design  characteristics  are  poorly  understood,  if  at  all. 
Consequently,  before  any  re-engineering  can  be 
accomplished,  it  is  usually  necessary  to  "reverse  engineer” 


a  system  to  document  its  capabilities,  structure,  design 
characteristics,  algorithms,  and  operation.  While  reverse 
engineering  efforts  can  and  do  succeed,  they  typically 
requite  an  enonnous  amount  of  time  and  eRort  that  coukl 
otherwise  be  avoided  if  the  systems  were  properly 
structured  and  judiciously  documented  in  the  first  place. 
Reverse  engineering  is  symptomatic  of  a  problem  -  not  a 
solution  to  it  In  other  words,  the  real  answer  isn’t 
developing  bigger  and  better  ways  (and  tools)  to  reverse 
engineer  systems,  but  to  concentrate  on  ways  of  acquiring 
(with  the  original  system)  an  effective  and  affordable  set 
of  baseline  documents  and  software  components  that  ate 
comprehendible  and  maintainable  for  the  life  of  the 
software  product  The  amount  of  money  that  is  being 
spent  on  reverse  engineering  of  software  products  is 
indicative  of  the  huge  savings  that  could  be  realized 
through  the  application  of  a  common  "software  product" 
reference  model. 

11.  THE  SOFTWARE  PRODUCT  FOR  MISSION 
CRITICAL  COMPUTER  RESOURCES 

This  paper  describes  a  generic  model  of  a  "software 
product”  for  Mission  Critical  Computer  Resources 
(MCCR).  The  application  to  MCCR  is  emphasized  to 
contrast  it  with  software  products  intended  for 
Management  Information  Systems  (MIS),  Automated 
Information  Systems  (AIS),  and/or  customary  business 
or  scientific  applications.  One  major  focal  point  for 
developing  next-generation  real-time  systems  is  the 
operating  system  [4].  The  distinguishing  characteristics 
of  a  software  product  designed  for  MCCR  revolve  around 
the  special  operating  system  and  run-time  software  features 
needed  to  support  the  time-critical  processing  requirements 
ofreal-timecompulersystems.  It  is  the  author’s  contention 
that  the  definition  of  the  software  product  intended  for 
MCCR  is  more  stringent  than  that  for  non  real-time 
software  applications  (e.g.,  MIS  and  AIS).  Consequently, 
the  approach  that  has  been  taken  is  to  develop  the  software 
product  model  around  MCCR  applications,  which  are 
considered  to  have  more  stringent  requirements.  An 
appropriate  subset  of  this  model  could  be  adopted  by  the 
MIS  and  AIS  communities. 

12.  THE  SOFTWARE  PRODUCT  MODEL:  SPORE 
The  software  product  model  that  is  described  in  this  paper 
is  referred  to  as  the  SPORE,  which  stands  for  SP^are 
product  QKganizalion  and  Enumeration.  As  depicted  in 
Figure  2,  the  Spore  Model  was  implemented  on  a  Apple* 
Macintosh*  personal  computer  using  TopDown*,  which 
is  a  COTS  tool  for  automating  system  and  process  design 
and  documentation.  TopDown*  was  chosen  because  it  is 
a  very  intuitive  ux>l  that  facilitates  the  breakdown  of  a 
complex  problem  into  small  manageable  parts,  where 
each  of  the  components  can  be  expanded  to  show  greater 
detail.  The  following  sections  of  this  paper  are  devoted  to 
describing  the  goals,  organization,  composition,  and 
characteristics  of  the  SPORE  Model. 

and  Macintoah  m  registered  trademarks  of  Apple  Computer. 
Inc.  TopDown  is  a  registered  trademark  of  Kaetron  S^ware  Corp. 


♦) 


4t 


•  • 


2ya-5 


FIgura  2.  TtM  Software  Product  for  Mission  Criticai  Computer  Resources 


13.  THE  SOFTWARE  PRODUCT  TOPOLOGY 
The  SPORE  Model  covers  the  entire  software  product 
topology  and  not  just  the  software  product  itself.  The 
software  product  topology  is  the  term  given  to  describe 
the  complete  software  product  and  its  operational 
environment  and  support  environment  As  shown  in 
Figure  3,  the  Software  Product  Topology  consists  of  the 
MCCR  computer  system  configuration,  the  software 
product  itself,  and  the  software  tool  resources  (tools  and 
manualsjrequiredforitslifecyclesupport.  By  definition, 
it  includes  all  of  the  information,  tool  resources,  and/or 
software  elements  needed  to  1)  install  and  operate  the 
software  product  in  its  t^ierational  environment,  2) 
regenerate  the  software  end-product,  and  3)  perform  life 
cycle  support  in  an  efficient  and  cost  effective  manner. 


14.  SPORE:  SOFTWARE  ERODUCT 

ORGANIZATION  AND  ENUMERATION 
The  SPORE  can  succinctly  be  described  as  a  graphical, 
hierarchical  model  of  the  software  product  (topology)  for 
MCCR.  It  provides  a  logical  decomposition  and 
description  rrf^all  the  elements  that  constitute  the  software 
product  along  with  the  other  elements  that  are  essential  to 
itsdeploymentand  life  cycle  support.  This  initial  SPORE 
model  is  considered  a  suitable  engineering  reference 
model  for  the  uniform  specification,  procurement, 
configuration  management,  and  life  cycle  support  of 
software  products  for  MCGl.  However,  as  discussed  in 
a  latter  section,  this  initial  version  of  the  SPORE  needs  to 
be  thoroughly  field  tested  using  actual  software  product 
data  obtained  from  projects. 
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The  SPORE  ModelisnoC  intended  ID  constrainadevekiper 
or  a  project  in  any  way.  Rather,  the  intent  is  to  provide  a 
superstructure,  or  reference  framework,  for  organizing 
and  enumerating  the  elements  that  comprise  the  software 
product  Hopefully,  any  project  can  use  the  SPORE,  or  a 
subset  thereof,  as  a  common  reference  model  (i.e.,  a 
software  template)  to  identify  and  describe  the 
configuration  and  contents  of  their  specific  software 
product  One  of  the  purposes  in  developing  SPORE  was 
to  establish  uniform  nomenclature  and  a  common  means 
of  viewing  a  software  product  to  gain  visibility  into  its 
specific  characteristics.  The  specific  goals  for  the 
develqpmentofthe  model  woe  the  following:  l)intuitive 
nomenclature,  2)  logical  breakdown,  3)  undersutndability 
at  top  levels  by  managementfproject  personnel,  4) 
understandability  at  lower  leveb  by  software  engineers, 
and  5)  complete  specification  of  required  components.  By 
definition,  the  required  components  were  purposely  limited 
to  only  those  absolutely  necessary  for  regenerating  the 
software  end-product,  performing  life  cycle  support  in  an 
etnciem  and  cost  effective  manner,  and  installing  and 
operating  the  software  product  in  its  operational 
environment. 


15.  SPORE  MODEL  DESCRIPTION 
As  shown  in  Figure  4,  the  top-level  elements  of  the 
SPORE  Model  are  1)  the  MCCR  Computer  System 
Coitflgurtttion,  2)  the  MCCR  Software  Product,  mi  3) 
the  ^ftware  Tool  Resources.  Together,  these  three  top- 
level  elements  describe  the  entire  software  product 
topology,  while  the  MCCR  Software  Product  element 
describe  the  software  product  itself.  These  three  top- 
level  elements  and  their  sub-elements  are  described  in  the 
following  sections  under  the  appropriate  beading. 


The  MCCR  Computer  System  Configuration  element 
defines  the  specific  hardware  and  software  resources  of 
the  operatioi^y  deployed  MCCR  system  for  which  the 
software  product  was  designed  to  operate.  As  shown  in 
Figure  S,  the  three  sub-elements  of  the  MCCR  Computer 
System  Configuration  element  are  1)  the  COMPUTER 
SYSTEM  HARDWARE,  2)  the  OPERATING  SYSTEM 
SOFTWARE,  and  3)  the  OTHER  APPUCATION 
SOFTWARE. 


Figure  5.  The  MCCR  Computer  System  Configuration 
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15.1.1  Computer  System  Hardware 

The  Computer  System  Hatdwaie  defines  the  particuUu 
hardware  features  of  the  deployed  computo-  system  that 
are  requited  for  the  proper  operation  of  the  software 
IModuct.  This  sub-element  typically  iiKludes  such  items 
as  the  specific  computer  make  and  model,  the  memory 
size,  auxiliary  hardware  items  (e.g.,  floating  point  or 
memory  management  unit),  and  peripheral  equipments 
such  as  hard  disk  drives,  storage  devices,  communication 
equipment,  and  other  special  gear  and/or  computer  system 
interfaces  the  software  product  must  be  compatible  with 
or  is  dependent  on. 

15.1.2  Operating  System  Software 

The  Operating  System  Software  defines  the  specific 
version  of  the  operating  system  software,  if  any,  that  is 
installed  on  the  system.  Typically,  this  is  the  operating 
system  software  that  is  provided  by  the  computer  hardware 
manufacturer.  However,  the  standard  operating  system 
software  that  usually  comes  with  the  computer  system 
may  not  necessarily  be  used  in  MCCR  applications.  For 
instance,  in  MCCR  systems  using  the  Ada  Programming 
Language,  the  run-time  software  is  frequently  acustomized 
software  system  consisting  of  a  separably  procured  Ada 
run-time  kernel  with  an  extensive  setof  software  extensions 
that  are  developed  to  provide  the  necessary  time-critical, 
real-time  software  capabilities. 

IS.U  Other  Application  Software 
The  Other  Application  Software  defines  application 
programs,  or  utilities,  or  other  software  that  the  software 
product  being  described  must  co-exist,  interface  with, 
and/or  be  compatible.  However,  the  software  described 
under  this  sub-element  is  not  a  part  of  the  software 
product,  although  it  may  possibly  be  separably  described 
as  another  software  product  that  shares  the  same  hardware 
resources. 


lU  The  BiCCRSiiOmft  Fradutl 

The  MCCR  Software  Product  element  provides  a  uniform 
and  generic  structure  for  identifying  and  specifying  the 
particular  components  and  attributes  of  a  software  product 
designed  for  MCCR.  As  shown  in  Figure  6.  the  four 
components  of  the  MCCR  Software  Product  are  l)the 
MCCR  SOFTWARE  END-PRODUCT,  2)  the 
SOFTWARE  REGENERATION  COMPONENTS,  3)  the 
SOFTWARE  DEVELOPMENT  ARTIFACTS,  and  4)  the 
SOFTWAREPRODUCTDOCUMENTATION.  Together, 
they  include  all  the  softwareeleinents,  data,  and  documents 
necessary  to  1)  regenerate  the  software  end-product,  2) 
perform  life  cycle  support  in  an  efficient  and  cost-effective 
manner,  and  3)  install  and  operate  the  software  product 
in  its  operational  environmenL 

15JI.1  MCCR  Software  End-Product 
The  MCCR  Software  End-Product  is  the  nomenclature 
used  to  refer  to  the  physical  software  entity  (typically 
encoded  on  a  tape,  cartridge,  or  other  hardware  media) 
that  is  ultimately  loaded  and  installed  on  the  MCCR 
computer  system.  This  is  the  executable  or  operational 
form  of  the  software  product  that  provides  the 
particular  functionality  and  capabilities  for  which  the 
software  product  was  designed  and  developed.  The 
end-product  constitutes  a  particular  release  or 
instantiation  of  the  software  product,  but  it  cannot  be 
directly  modified  or  maintained,  because  it  is  coded  in 
a  rigid  form  dictated  by  the  computer  system’s 
instruction  set  architecture.  As  shown  in  Figure  7,  the 
MCCR  Software  End-Product  is  comprised  of 
EXECUTABLE  CODE  ELEMENTS,  EXECUTION 
SUPPORT  ELEMENTS,  and  LOAD-AND-EXECUTE 
INSTRUCTIONS.  The  EXECUTION  SUPPORT 
ELEMENTS  are  further  decomposed  into  Library 
Elements,  External  Data  Elements,  and  Operating 
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Figure  6.  The  Four  Components  of  the  MCCR  Software  Product 


•  • 


2<>S-8 


Figure?.  The  MCCR  Software  End-Product 


System  Elements  (which  identifies  the  dependencies,  if 
any.  on  the  MCCR  Operating  System  Software).  The 
LOAD-AND-EXECUTE  INSTRUCTIONS  describe  how 
the  MCCR  Software  End-Product  is  to  be  loaded  and 
installed  into  the  computer  system.  Occasionally,  the 
software  end-product  may  be  burned  into  Read  Only 
Memory  (ROM)  or  some  other  form  of  permanent  or 
semi-permanent  storage,  in  which  case  the  software  is 
referred  to  as  "firmware".  In  this  case,  the  LOAD- 
AND-EXECUTE  INSTRUCTIONS  would  describe  the 
procedure  for  physically  installing  the  firmware  device, 
while  the  actual  "bum-in"  of  the  fumware  device 
would  be  described  in  a  special  section  of  the  Software 
Regeneration  Guide  that  is  required  as  part  of  the 
software  product  documentation. 


15.2  J  Software  Regeneration  Components 
The  Software  Regeneration  Components  consist  of 
those  components  and  only  those  components  that  are 
necessary  to  recreate  the  end-product  starting  from  the 
source  code.  The  regeneration  components  produced 
by  each  stage  of  the  software  regeneration  process  are 
included  to  enable  step-by-step  verification  and 
validation  of  the  entire  process.  The  regeneration 
process,  itself,  is  described  in  the  Software 
Regeneration  Guide  that  is  required  as  part  of  the 
software  product  documentation.  As  shown  in  Figure 
8,  the  generic  software  regeneration  components 
include  SOURCE  CODE  Regeneration  Elements, 
OBJECT  CODE  Regeneration  Elements, 
INTERMEDIATE  LIBRARY  Regeneration  Elements, 


Figure  8.  Software  Regeneration  Components 
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OTHER  INTERMEDIATE  DATA  Regeneration 
Elements,  EXECUTION  SUPPORT  Regeneration 
Elements  (Librsries  and  External  Data),  and 
EXECUTABLE  CODE  Regeneration  Elements.  Each 
of  these  individual  software  regeneration  components 
is  broken  down  into  three  sub-components:  l)the 
specific  Build  Instructions  that  describe  the  procedure 
for  creating  the  regeneration  component,  2)  the 
specific  Data  Elements  that  makeup  the  regeneration 
component,  and  3)  the  specific  Presentation 
Information  for  displaying  andA>r  printing  the 
particular  regeneration  component 

1S,2J  Software  Development  Artifacts 
The  Software  Development  Artifacts  are  software 
development  entities  ot  by-products  that  were 
produced  and  used  in  the  original  software 
di  i '  ?  lopmeni  process  but  are  not  required  for 
regeneration  of  the  software  end-product  By 
definition,  these  artifacts  are  divided  into  two  groups: 

1)  ESSENTIAL  SOFTWARE  DEVELOPMENT 
ARTIFACTS  and  2)  OPTIONAL  SOFTWARE 
DEVELOPMENT  ARTIFACTS,  as  illustrated  in  Figure 
9.  Although  the  artifacts  may  have  played  a  significant 
role  during  the  development  phase  diey  may,  or  may 
not  be  of  particular  value  in  the  life  cycle  support 
phase.  Subsequently,  those  artifacts  that  are 
considered  to  be  essential  to  performing  software  life 
cycle  support  in  an  efficient  and  cost-effective  manner 
are  designated  as  being  ’ESSENTIAL';  all  others  are 
designated  as  being  'OPTIONAL'.  While  the  exact 
determination  is  somewhat  subjective,  some  artifacts 
are  clearly  essential  and  some  are  obviously  optional. 
Two  examples  of  such  artifacts  are  Program  Design 
Language  (PDL)  descriptions  and  Software 


Development  Metrics,  respectively.  If  a  PDL 
description  the  software  design  was  produced  during 
the  development  phase  it  would  definitely  be  a  very 
valuable  artifact  to  those  responsible  for  maintaining 
and  enhancing  the  software  (and  thus  designated 
'ESSENTIAL').  Although  software  metrics  produced 
during  the  development  phase  may  be  valuable  in 
providing  status  information  they  would  hardly  be 
essential  to  performing  software  life  cycle  support  (and 
thus  designated  'OPTIONAL')  since  they  represent  past 
history,  it  should  be  noted  thatjust  because  an  artifact 
is  designated  OPTIONAL'  does  not  mean  that  it  isn’t 
valuable  or  that  it  shouldn’t  be  a  contractual 
requirement.  The  SPORE  approach  was  predicated  on 
defining  the  minimum  required  to  perform  software  life 
cycle  sigrport  in  an  efHcient  and  cost-effective  manner 
so  that  life  cycle  support  could  not  be  compromised 
through  uuloring,  contract  negotiations,  or  any  other 
means.  However,  the  approach  does  allow  and,  in  fact, 
encourages  a  project  to  "tailor  up"  their  software 
requirements  to  meet  qrecific  needs  by  specifying  any 
number  of  'CffTIONAL'  artifacts.  This  has  the  added 
benefit  of  being  able  to  separately  cost  them  out  as 
optional  line  items  in  a  contract  so  that  their  cost 
effectiveness  can  be  determined  on  a  case-by-case 
basis.  For  example,  a  set  of  regression  tests  for  the 
software  product  could  be  specified  as  an  qrtional 
arti&Kt  to  be  separately  costed  out  Based  on  the 
proposals  and  bids  that  were  submitted,  the  procuring 
activity  could  determine  if  the  development  contractor 
should  produce  the  regression  tests,  or  whether  it 
would  be  mme  cost-effective  to  hire  an  Independent 
Verification  and  Validation  (IV&V)  contractor  to 
develop  them,  or  have  their  own  project  personnel 
develop  the  regression  test  suite. 
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\SJ.A  Software  Product  Documentation 

The  Softwiue  Product  Documentation  consists  of  a 
suite  of  software  documents  that  describe  the  software 
system  architecture  and  requirements,  its  capabilities 
and  operation,  how  the  software  is  designed  and 
constructed  including  its  interfaces,  the  steps  required 
to  regenerate  the  software  end-product,  how  to  install 
and  operate  the  software  product  in  its  operational 
environment,  and  other  pertinent  information  on 
performing  life  cycle  support  Three  ground  rules  that 
apply  to  all  of  the  documents  are  that  they  must'  1) 
conform  to  the  minimum  information  requirements 
specified  for  each  document  (in  tmy  appropriate  format 
that  aids  understanding  and  readability),  2)  be 
delivered  in  an  electronically  readable  and  processable 
form  and  include  a  rqprodocible  hard-copy  document 
and  3)  include  a  copy  of  the  Build  Instructions, 
Document  Data  Elements  (Text  and  Graphics),  and 
Presentation  Infmmation  that  are  necessary  to 
regenerate  each  of  the  documents  and  create  a  hard¬ 
copy.  The  Software  Produa  Documentation  suite 
constitutes  a  "straw  man"  set  of  documents  for  a 
software  product  The  qrecific  drKuments  being 
proposed  were  derived  from  knowledge  gained  from 
performing  an  m-depth  critique  cS  the  deficiencies  d 
existing  software  documentation  standards  and  from 
developing  the  SPORE  Model  of  the  software  product 
As  shown  in  Figure  10.  the  Srrftware  Product 
Documoiiation  is  divided  into  five  categories:  1) 
SOFTWARE  SPECIFICATION  DOCUMENTS,  2) 
RUN-TIME  SOFTWARE  DOCUMENTATION,  3) 
OPERATIONAL  SUPPORT  DOCUMENTS,  4) 
REGENERAHON  SUPPORT  DOCUMENTS,  and  5) 
SOFTWARE  ARTIFACT  DOCUMENTS. 


15.2.4.1  Software  Specification  Documents 

The  Software  Specification  Documents  are  analogous 
to  the  classical  software  descriptive  documents  and 
include  a  Computer  System  Architecture  Document,  a 
Software  Requirements  Ttocumem,  a  Software  Interface 
Document,  and  a  Software  Design  Document. 

15.2.4.2  Run-Time  Software  Documeniaiion 

The  Run-Time  Software  Documentation  describes  the 
specialized  MCXTR  system  software  which  provides  all, 
or  part,  of  the  real-time  Application  Program  Interface 
(APO  with  the  computer  hardware  resources.  The  run¬ 
time  software  typically  includes  an  executive,  system 
utilities,  interrupt  handlers,  I/O  device  drivers,  etc.  A 
separate  document  was  considered  essential  for  the 
run-time  softw»e  because  it  has  the  most  stringent 
design  considerations,  the  highest  degree  of 
complexity,  and  represents  the  greatest  maintenance 
challenge, 

15.2.4.3  Operational  Suimott  Documents 
The  Operatioiud  Support  Documents  include  a 
Software  Installation  Guide,  a  Operator  and/or  User 
Manual(s),  and  a  System  Crash  Recovery  Guide. 

These  documents  describe  the  man-machine  interface 
and  the  basic  system  software  features  that  are  required 
to  support  a  system  operator  mdlot  end-user  in  the 
opeiatioiial  environment. 

15.2.4.4  RggHieratign  Subbmi  Pocumenis 
The  Regeneration  Support  Documents  include  a 
SPORE  Description  Guide,  and  a  Software 
Regeneration  Guide.  These  documents  identify  the 
particular  SPORE  components  for  the  strftware  product 
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Figure  11.  Software  Tool  Resources 


(teliverable  and  the  process  for  regenerating  the 
software  end-product  form  the  data  and  information 
elements  contained  in  the  SPORE,  respectively. 

152.4.5  Software  Artifact  Documentation 
The  Software  Artifact  Documentation  includes 
documentation  on  each  of  the  ESSENTIAL 
Developmental  Art^acts  and  OPTIONAL 
Developmental  Artifacts  describing  the  specific  nature 
and  characteristics  of  the  artifact,  how  they  are  used, 
the  associated  tool(s),  relevant  examples,  and  pertinent 
information  on  the  artifact  development  process. 

ISJ  Software  Tool  Resources 
The  Software  Tool  Resources  element  identifies  all  the 
resources  (i.e.,  software  tools,  facilities,  and  manuals) 
that  were  used  to  develop  the  software  product  and 
which  are  required  to  provide  life  cycle  support.  As 
shown  in  Figure  1 1,  the  three  sub-elements  of  the 
Software  Tool  Resources  are  1)  the  SOFTWARE 
TOOLS.  2)  the  DESCRIPTION  OF  HOST 
COMPUTER  SY^EM  FACILITIES  and  3)  the 
SOFTWARE  TOOL  MANUALS.  Together,  they 
provide  the  information  on  the  tools,  descriptive  tool 
manuals,  and  host  computer  systems  (on  which  the 
tools  reside)  that  is  required  to  1)  regenerate  the 
software  end-product,  2)  perform  life  cycle  support  in 
an  efficient  aid  cost-effective  manner,  and  3)  install 
and  operate  the  software  product  in  its  operational 
environment. 


15  J.l  Software  Tools 

The  Software  Tools  sub-element  includes  all  the  tools 
that  were  used  in  the  development  of  the  software 
product  and  are  requued  to  provide  life  cycle  support. 
This  includes  the  tools  that  were  used  to  i^oduce  the 
software  documentation.  As  shown  in  Figure  1 1,  the 
SOFTWARE  TOOLS  sub-element  is  comprised  of 
MCCR  Resident  Tools  and  Software  Development 
Tools.  The  MCCR  Resident  Tools  include  any  tools 
that  run  on  the  actual  MCCR  computer  system  and  are 
used  to  support  the  loading,  installation,  or  operation  of 
the  software  end-product.  The  Software  Development 
Tools  are  further  broken  down  into  Software 
Regeneration  Tools.  Software  Development  Artifact 
Tools,  and  Software  Documentation  Tools. 
corresponding  to  three  (of  four)  components  of  the 
MCCR  Software  Product  It  should  be  noted  that  if 
any  of  the  required  tools  is  also  a  developmental  item, 
as  opposed  to  a  non-developmental  COTS  tool,  it  must 
be  delivered  as  a  separate  software  product  (in 
conftmnance  with  the  SPORE  Model),  itself,  so  that 
the  procuring  activity  will  have  the  means  to  perform 
life  cycle  support  should  that  become  necessary. 

15  Description  of  Host  Computer  System 
Facilities 

The  purpose  of  this  sub-element  is  to  provide  an 
overview  and  a  summary  of  the  computer  system 
facilities  that  were  used  to  host  the  tool  resources  used 
in  the  development  effort  and  which  are  still 
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applicable  for  siqiponing  the  ptesciibed  regeneialion 
toob,  artifact  ux^.  and  documentation  tools  specified 
above. 

ISJ  J  Software  Tool  ManualB 

The  Software  Tool  Manuals  sub-element  includes  all 
the  off-the-shelf  documents  that  are  available  from  the 
tool  manufacturer  to  describe  its  use.  opmuion, 
capabilities,  and  application.  As  shown  in  Figure  1 1 , 
the  Software  Tool  Manuals  sub-element  consists  of 
USER  f.1.\NUALS,  REFERENCE  MANUALS,  and 
OTHER  MANUAU  AND  DOCUMENTS.  These  three 
generic  categories  are  provided  to  accommodate  the 
high  degree  of  variability  in  tool  manuals  and  tool 
documents. 

16.  FUTURE  SPORE  DEVELOPMENTS 
Future  SPORE  developments  are  broken  down  into 
near-term  and  long-term  development  efforts  as 
described  below. 

16.1  Near-Term  Devehipmeiil  Effort 

The  current  SPORE  Model  is  a  developmental  version. 
It  needs  to  be  "product’ '  ’'efore  it  can  be  considered 
ready  for  use  by  projects.  _  '..equently,  the  next  step 
in  the  development  of  SPORE  will  be  to  thoroughly 
Held  test  the  model  and  refine  it  using  "real-world" 
software  product  data.  Several  candidate,  software- 
intensive  projects  of  significant  size  and  complexity 
have  been  identified  that  can  serve  as  suitable  testbeds. 
Another  significant  task  that  remains  to  be  completed 
is  the  development  of  the  detailed  specifications  for  the 
proposed  software  product  documentation  suite. 

16.2  Long-Term  Development  Effort 

The  ultimate  goal  that  is  envisioned  is  the  evolutionary 
development  of  a  full-blown  SPORE  that  would  be  a 
complete  Software  £roduct  Open  Repository/ 
Environment  that  is  built  around  an  open-systems 
architecture.  Such  a  system  could  provide  a  common 
means  of  gracefully  delivering  and  transitioning 
software  products  from  one  government  activity  to 
another,  from  a  sub-contractor  to  a  system  prime 
contractor,  or  from  a  contractor  to  a  government 
activity.  In  terms  of  capabilities,  this  ultimate  SPORE 
system  would  support  the  following  scenario:  1)  a 
complete  software  (xoduct  is  delivered  on  a  single, 
high  capacity,  optical  disk,  2)  the  optical  disk  is 
inserted  into  the  systnn  and  the  software  product  is 
loaded  into  SPORE,  3)  a  software  manager  accesses 
SPORE  from  a  workstation  and  obtains  on-line  access 
to  the  delivered  software  product,  4)  a  modem 
Graphical  User  Interface  (GUI)  enables  the  manager  to 
view  a  graphical  decomposition  of  the  software  product 
on  a  display  monitor,  5)  the  manager  invokes  a 
command  to  obtain  a  standard  set  of  software  product 
metrics,  6)  the  SPORE  system  responds  by  displaying 
a  summary  report  of  the  software  product  which 
includes  statistics  on  the  software  end-product,  the 
number  of  individual  program  modules  (including  a 


listing  of  their  name,  source  code  count,  programming 
language  used,  etc.),  and  the  numbo^  of  descriptive 
software  documents  (including  a  listing  of  their  title 
and  page  count).  '’)  the  software  manager  initiates  a 
Configuration  Management  (CM)  assessment 
curability  to  check  the  status  of  the  software  product, 

8)  the  SPORE’S  CM  system  displays  a  list  of  items  that 
are  missing  in  the  software  product  and  flags  numerous 
incofisisteiKies  and  several  potential  problem  areas,  9) 
the  numager  invokes  a  Software  Quality  Assurance 
(SQA)  analysis  capability,  10)  the  SPORE's  SQA 
system  performs  complexity  measures  on  all  the 
software  modules  and  reports  back  on  the  modules  that 
have  exceeded  a  pre-specified  limit,  1 1)  the  manager 
makes  an  inquiry  about  a  specific  program  module, 

1 2)  the  system  responds  by  displaying  the  complexity 
graph  for  the  selected  module,  13)  the  manager 
requests  a  summary  report,  14)  the  system  produces  a 
hard-copy  summary  of  all  the  inspections  and  tests  that 
were  performed  during  the  session,  1 S)  the  manager 
creates  a  backup  and  provides  the  authorization  to 
allow  the  SQA  Team  (which  is  responsible  for 
acceptance)  to  access  the  software  product,  and  16)  the 
manager  suddenly  wakes  up  and  remembers  there  is 
"another  meeting"  to  go  to,  and  that  this  dreaming  - 
about  how  things  could  be  -  has  to  end! 
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Discussion 


Question  -  J.  BART 

•  t 

Have  you  applied  SPORE  lo  a  program?  Are  there  future  programs  on  which  the  SPORE  approach  will  be  applied? 

Reply 

The  concept  of  SPORE  has  been  applied  to  projects  indirectly  in  the  form  of  a  software  data  base  that  was  an  integral 

part  of  a  tightly  coupled  Software  Engineering  Envinnment  (SEE).  •  #  ( 

The  current  SPORE  effort  is  a  new  development  and  the  SPORE  model  needs  to  be  "productized"  using  actual  project 
data  before  it  can  be  considered  eally  for  general  project  application.  Two  candidate  software-intensive  projects  of 
significant  complexity  have  be<.ii  identified  that  will  serve  as  suitable  test  beds  for  this  purpose. 

The  long  rang.,  goal  is  to  investigate  the  feasibility  of  using  SPORE  as  the  basic  building  block  for  a  Software  Product  ^ 

(3pen-archiiecture  Repository/Environment  (SPORE). 
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SDE’s  FOR  THE  YEAR  2000  AND  BEYOND:  AN  EF  PERSPECTIVE. 


D.J. Goodwin 

British  Aerospace  Defence  (Military  Aircraft  Division) 
Warton  Aerodrome 
Warton 

Preston  PR4  lAX,  UK 


1  SUMMARY. 

The  process  of  selecting  a  Software 
Development  Environment  for  the  embedded 
software  of  a  large,  complex  military  aircraft 
project  can  be  long  and  costly. 

This  paper  describes  the  process  adopted  on 
the  European  Fighter  Aircraft  project  (EFA) 
by  British  Aerospace  (BAe)  from  the  initial 
research  and  prototyping  exercises  perform.?d 
in  the  seventies  through  to  the  demonstration 
of  the  technology  on  the  Experimental 
Aircraft  project  and  finally  leading  to  the 
collaboration  with  the  Eurofighter  Partner 
Companies  (EPC’s),  building  on  European 
Software  experience  to  specify,  procure  and 
release  the  EFA  Software  Development 
Environment  (EFA  SDE). 

The  paper  goes  onto  describe  those  issues  that 
are  arising  within  the  EF  forum  that  could 
influence  the  development  of  SDE’s  for  future 
military  aircraft  projects. 

This  paper  is  written  from  the  viewpoint  of 
British  Aerospace  and  does  not  necessarily 
reflect  the  views  of  the  other  Eurofighter 
companies. 

2  LIST  OF  SYMBOLS. 

AB  Allocated  Baseline 
BAe  British  Aerospace 
CDR  Critical  Design  Review 

CORE  controlled  Requirements 
Expression 

DoD  Department  Of  Defence 
EAP  Experimental  Aircraft  Programme 
EF  Eurofighter 

EFA  European  Fighter  Aircraft 

EF  SDE  Eurofighter  Software  Development 
Environment 

EPC  Eurofighter  Partner  Companies 

EPOS  Engineering  And  Project 

Management  Oriented  Support 
System 

FB  Functional  Baseline 
FCA  Functional  Configuration  Audit 

HOOD  Hierarchical  Object  Oriented 
Design 

IPSE  Integrated  Project  Support 
Environment 


LDRA  Liverpool  Data  Research 
Associates 

MASCOT  Modular  Approach  to  Software 
Construction  and  Test 

MDS  Microprocessor  Development 
System 

PB  Product  Baseline 
PCA  Physical  Configuration  Audit 
PDR  Preliminary  Design  Review 
PVL  Programme  Validation  Limited 

SAFRA  Semi- Automated  Functional 
Requirements  Analysis 

SDE  Software  Development 
Environment 

SSR  Software  Specification  Review 
STD  Standard 

TRR  Test  Readiness  Review 
VMS  VAX  Management  System 

3  PREPARING  FOR  EFA. 

At  British  Aerospace  the  investigations  into 
the  requirements  of  the  SDE  for  EFA  began 
in  1978.  At  that  time  it  was  recognized  that  if 
EFA  was  implemented  at  the  software 
productivity  levels  being  found  on 
TORNADO,  Software  Development  effort 
would  be  excessive  (8.1). 

If  EFA  was  to  be  affordable  software 
productivity  had  to  improve. 

3.1  PRE  EAP. 

Looking  ahead  to  EFA  it  was  clear  that  a 
step  change  in  productivity  was  necessary. 
Throughout  industry  and  the  academic  world 
effort  was  being  applied  to  tackle  this 
problem.  Although  recognising  this  and  in 
fact  heavily  leaning  on  the  results  of  this 
activity  BAe  could  not  afford  to  wait  and 
hope  that  this  would  solve  the  problem.  BAe 
therefore  embarked  on  a  series  of  risk 
reduction  exercises  targeted  at  demonstrating 
the  required  productivity. 

To  begin  with  a  software  development 
process  model  was  established  following  the 
now  traditional  waterfall  approach.  This 
model  formed  the  basis  of  SAFRA 
(Semi-Automated  Functional  Requirements 
Analysis).  The  principle  underpining  SAFRA 
is  RIGHT  FIRST  TIME  achieved  through 
early  detection  of  errors.  To  achieve  the 
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required  improvement  in  productivity  every 
activity  must  add  value  and  all  non-value 
added  activities  must  be  eliminated. 

The  SAFRA  lifecycle  is  shown  in  figure  1. 

The  methods  adopted  on  SAFRA  were 
controlled  Requirements  Expression 
(CORE),  Modular  Approach  to  Software 
Construction  And  Test  (MASCOT)  and 
Enhanced  PASCAL  was  adopted  as  the 
project  language.  The  supporting  toolsets 
were  the  CORE  Workstation  and 
PERSPECTIVE.  In  addition  a 
micro- Processor  Development  System  (MDS) 
was  used  to  support  low  level,  real  time 
software  testing. 

The  principles  of  each  SAFRA  phase  can  be 
summarised  in  figure  2. 
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3.3  POST  EAP. 

Just  prior  to  the  completion  of  the  EAP 
programme  the  requirements  for  the 
European  Fighter  Aircraft  began  to  be 
defined. 

It  has  been  recognized  by  the  EFA  Customer 
that  in  addition  to  technical  and 
performance  requirements  there  is  a  real 
need  to  minimise  the  cost  of  ownership  of 
EFA.  To  this  end  a  strategy  was  formed  to 
ensure  that  throughout  its  service  life  EFA 
will  be  easy  to  maintain  and  modify. 

Part  of  this  strategy  centred  around  the 
development  of  software.  It  was  perceived 
that  by  controlling  the  software  development 
process,  significant  savings  could  be  made  in 
the  long  term.  The  main  principles  behind 
the  software  development  strategy  are;- 

-  the  uniform  application  of  a  common 
software  development  process, 

-  the  adoption  of  a  project  standard 
programming  language, 

-  the  use  of  a  standard  processor 
throughout  the  architecture, 

-  the  use  of  a  common  toolset  for 
software  development. 


FIGURE  2:  SAFRA  Concepts. 

-  Inputs  for  each  activity  should  be 
subject  to  strict  quality  control  to 
ensure  a  stable  baseline. 

-  The  activity  must  be  supported  by  a 
defined  method  to  ensure  consistency 
and  repeatability. 

-  Each  method  should  be  supported  by 
a  tool  to  ensure  quality  and 
productivity. 

-  Each  output  should  be  subject  to  strict 
quality  control  to  ensure  a  stable 
baseline  for  the  next  activity  in  the 
lifecycle. 

The  concepts,  methods  and  tools  of  the 
SAFRA  model  were  tried  out  on  several 
study  projects.  Sufficient  confidence  in  the 
SAFRA  approach  was  established  to  enable 
it  to  be  adopted  on  the  PI  10  combat  aircraft 
project  (precursor  to  EFA)  and  finally  as  the 
development  approach  on  the  Experimental 
Aircraft  Programme  (EAP). 

3.2  EAP. 

The  results  of  the  application  of  SAFRA  on 
EAP.  [8.1]  were  very  promising  and  showed 
that  by  adopting  controlled  methods, 
procedures  and  tools  the  productivity 
required  for  EFA  could  be  achieved. 

In  addition,  a  significant  improvement  in  the 
quality  of  the  final  product  over  that  of 
previous  projects  was  achieved.  The 
approach  had  been  able  to  detect  errors 
earlier  in  the  development  lifecycle  than  on 
previous  projects. 


4  THE  EFA  SDE. 

These  principles  outlined  above  were 
expanded  in  the  EFA  Development  Contract 
to  establish  the  requirements  for  the  EFA 
SHE. 

4.1  CRITICAL  REQUIREMENTS. 

The  EF  Software  development  process  is 
required  to  be  common  throughout  the 
project.  The  Development  Contract  cited 
DoD-std-2167  Software  Development  [8.2]  as 
the  required  development  model. 

In  order  to  define,  specify  procure  and 
release  the  EF  software  Methods  Procedures 
and  tools  a  multi-National  Software 
Management  Group  consisting  of 
representatives  from  each  EF  Partner 
Company  was  established  at  British 
Aerospace,  Warton. 

The  first  task  of  this  group  was  to  tailor  the 
DoD  standards  to  accommodate  the 
experience  that  had  been  gained  from 
projects  like  EAP. 

The  team  set  about  defining  a  set  of 
standards  covering  Software  Development, 
Software  Configuration  Management  and 
Software  Quality  Evaluation. 

An  overview  of  the  EF  software 
development  process  is  shown  in  figure  3. 

The  development  process  has  to  cater  for 
differing  software  criticality  levels 
encompassing  both  safety  critical  and 
mission  critical  software. 

The  EFA  system  and  software  is 
incrementally  developed  with  increasing 
functionality  and  clearance  over  time. 
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The  experience  from  each  EPC  on  software 
development  methods  was  used  to  define  the 
EF  Method  set.  The  methods  chosen  to 
support  the  EFA  lifecycle  were:- 

-  controlled  Requirements  Expression 
(CORE)  for  requirements  capture  and 
system  design, 

-  Hierarchical  Object  Oriented  Design 
(HOOD)  for  software  design, 

-  Ada  and  a  safe  Ada  subset,  for  safety 
critical  software,  as  the  programming 
languages, 

-  and  the  use  of  Host  computer  and 
Target  emulation  for  software  testing. 

The  benefits  arose  from  building  on  EAP 
experience  (CORE  and  Target  emulation), 
adopting  industry  standards  (Ada)  and 
tracking  leading  edge  expertise  (HOOD).  The 
next  challenge  facing  the  Software 
Management  team  was  to  specify  and 
procure  a  set  of  tools  to  support  these 
methods  and  to  move  from  a  program 
support  to  a  project  support  environment. 

4.2  SELECTION  PROCESS. 

The  fundamental  requirements  driving  the 
EF  Toolset  selection  were 

-  Each  tool  must  be  compatible  with 
VAX  VMS  and  run  either  on  a  VAX 
Terminal  or  a  VAX  Station. 

-  The  tool  must  support  EF  methods, 
process  or  the  development  and  testing 
of  Ada  programs. 

-  Each  tool  will  drive  productivity  and 
quality  into  th,*  EF  Process. 

The  Software  Management  team  performed  a 
survey  of  the  software  tool  market  to 
establish  the  state  of  the  art. 

As  a  result  of  this  survey,  a  set  of  tool 
specifications  were  written  defining  the 
required  functionality  and  performance  of 
the  EF  SDE.  For  the  majority  of  the  tools  a 
competitive  tendering  exercise  was 
conducted  with  tenders  received  from 
several  of  the  major  software  tool  suppliers 
in  Europe.  Each  offered  tool  was  technically 
evaluated  against  a  checklist  of  requirements 
by  the  Software  Management  team.  A 
separate  commercial  tendering  exercise  was 
handled  by  EF  Procurement. 

The  final  outcome  of  the  tendering  exercise 
resulted  in  the  selection  of  the  EF  SDE.  The 
toolset  of  the  EF  SDE  is  described  below. 

4.3  THE  EF  SDE  TOOLSET. 

The  EF  Software  tools  are  EPOS,  CORE 
Workstation,  HOOD  Toolset,  EFA  Ada 
Compilation  System,  SPARK  Analyser, 
LDRA  TESTBED  and  the  EF  IPSE.  It  is  not 
the  purpose  of  this  paper  to  describe  in 
detail  the  EF  toolset  however,  a  brief 
overview  of  each  tool  is  provided  for 
information. 


4J.J  EPOS. 

EPOS  (Engineering  Project  management 
Oriented  support  System)  is  a  tool 
developed  by  GPP  mbH  in  Germany.  It  is 
used  on  EFA  to  structure  English 
requirements  documents  into  a  more 
modular,  traceable  form.  It  enables  each 
requirement  contained  in  such  documents 
to  be  allocated  a  unique  requirements 
identifier. 

Eg  ( Note:  The  following  fictitious 
e.xamples  are  provided  to  illustrate 
the  technique  )■ 

Requirement  10431(4233). 

The  aircraft  will  be  capable  of 
releasing  its  payload  at  all  altitudes 
within  the  flight  envelope. 

Requirement  20423(1454). 

The  aircraft  will  be  capable  of 
performing  its  mission  in  all 
weathers. 

This  number  is  then  used  throughout  the 
remainder  of  the  development  as  a 
reference  for  compliance  traceability.  The 
EPOS  tool  automatically  supports  a 
compliance  check  listing  where 
requirements  have  been  fulfilled  and 
highlighting  any  unfulfilled  or  partly 
fulfilled  requirements. 

4.3.2  CORE  Workstation. 

Ihe  CORE  Workstation  is  a  VAX  Station 
based  tool  produced  by  British  Aerospace 
to  support  the  CORE  method.  The  tool 
consists  of  a  diagram  and  text  editor, 
report  generator  and  database  checker.  The 
tool  also  supports  individual  diagram  and 
text  note  configuration  control. 

4.3.3  HOOD  Tool. 

The  HOOD  Toolset  is  a  VAX  Station  based 
tool  produced  by  IPSYS  Ltd.  The  HCXDD 
tool  consists  of  a  diagram  and  text  editor, 
report  generator  and  database  checker.  It 
also  has  a  facility  for  automatic  code 
generation  (Ada).  The  tool  follows  the 
method  outlined  in  the  HOOD  Reference 
Manual  [8.3]. 

4.3.4  Ada  Compilation  System. 

The  EFA  Ada  Compilation  System  is  a 
VAX  VMS  based  toolset  comprising:- 

EDS  SCICONS’s 

XD  Ada  Target  compiler, 

XD  Ada  MC68020  HP 
Emulator  interface 

DIGlTALS’s 

VAX/VMS  Ada  Host 
compiler. 

Language  Sensitive  Editor, 
Source  Code  Analyser 
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Perfunnance  Coverage 
Analyser, 

Softspeed's 

MC68020  simulator 

The  complete  toolset  is  procured  from  EDS 
SCICON.  The  Ada  Compiler  is  used 
throughout  the  EFA  project  and  is 
managed  by  a  combined 
Customer/Contractor  management  group. 
This  group  controls  the  baseline  compiler 
and  plans  for  changes  to  that  baseline. 

4.JJ  SPARK  Examiner. 

Safety  critical  software  for  EFA  must  be 
written  to  a  (Safe)  Ada  subset  which 
restricts  the  use  of  Ada  to  a  deterministic 
set  of  features.  This  subset  is  enforced 
through  compliance  with  the  SPARK  Ada 
subset  and  checked  using  the  SPARK 
Examiner  tool. 

The  SPARK  Examiner  (Version  A)  is 
produced  by  PVL  Ltd.  it  is  used  on  EFA 
to  statically  analyse  safety  critical  software. 
It  checks  conformance  with  the  SPARK 
Ada  language  subset  and  performs  control 
flow,  data  flow  and  information  flow 
analysis. 

4.3.6  LDRA  Testbed. 

The  TESTBED  tool  is  produced  by  the 
Liverpool  Data  Research  Associates  Ltd.  It 
is  used  on  EFA  for  both  static  and 
dynamic  analysis  of  EFA  code.  It 
determines  code  metrics  such  as  McCabe 
Cyclomatic  complexity,  it  provides  test 
effectiveness  ratios  for  statement,  branch 
and  Linear  Code  Sequence  and  Jump 
coverage.  It  also  performs  Data  Set  analysis 
mapping  test  cases  to  code  analysed. 

4.3.7  EF  Integrated  Project  Support 
Environment  (IPSE). 

The  EF  IPSE  is  based  on  the 
PERSPECTIVE  KERNEL  produced  by 
EDS  SCICON.  The  EF  IPSE  performs 
automated  configuration  management  of 
the  products  produced  during  the  system 
and  software  development  lifecycle,  it 
enables  the  other  tools  to  be  integrated  into 
the  IPSE  allowing  full  control  of  the 
configuration  of  tool  products 
automatically.  It  also  allows  for  the 
controlled  definition,  allocation, 
development  and  return  of  specific 
packages  of  software  development. 

Whereas  EAP  utilised  an  environment  for 
support  of  software  design,  code  and  test, 
on  EFA  a  full  IPSE  is  necessary  in  order 
to  control  a  much  larger  product  and  still 
achieve  productivity  levels  similar  to  those 
on  EAP. 

The  IPSE  structure  is  represented  in  the 
figure  4. 


The  concept  is  that  all  software 
development  work  is  carried  out  within  the 
IPSE.  This  will  enable  every  package  of 
work  to  be  configured  from  its  inception. 

The  IPSE  supports  a  geographically 
distributed  database  allowing  packages  to 
be  tracked  as  they  are  sent  throughout 
Europe.  This  will  support  large,  distributed 
team  working. 

Currently  HOOD  and  Ada  are  integrated 
into  the  IPSE.  Other  tools  can  be 
integrated  when  necessary  through  use  of 
the  ireE  developers  kit. 

The  IPSE  supports  the  EF  configuration 
management  procedures  and  forms  and 
therefore  allows  automated  control  of 
change  and  tracking  of  configuration 
status. 

4.4  CURRENT  STATUS  OF  EF  SDE. 

The  EF  SDE  has  been  fully  released  to 
project  and  is  being  used  i^or  the 
development  of  the  current  EFA 
development  software.  The  effectiveness  of 
the  toolset  has  yet  to  be  determined  and  will 
only  become  fully  clear  at  the  end  of 
development. 

S  LOOKING  TO  THE  FUTURE. 

A  number  of  issues  have  arisen  during  the 
development  of  EFA  software.  It  may  be 
possible  to  accommodate  them  within  the 
timescales  of  EFA  but  this  will  be  based  on  a 
case  by  case  cost/benefit  analysis. 

The  root  of  these  problems  which  are 
highlighted  by  these  issues,  centres  around  the 
fact  that  for  the  past  15  to  20  years  the 
discipline  of  software  engineering  has  been 
very  heavily  biased  towards  tool  development. 
Development  of  processes  and  methods  has  not 
matched  the  speed  of  tool  development. 

If  we  are  to  make  any  real  progress  in  the 
future,  effort  has  to  switch  from  developing 
faster  and  more  capable  tools  to  developing 
repeatable,  measurable  development  processes 
that  integrate  into  an  overall  aircraft 
development  programme. 

We  must  put  focus  on  the  products  that  we  are 
developing  rather  than  on  the  tools  to  support 
them. 

I  have  described  some  of  the  particular  issues 
arising  from  the  EF  forum  below. 

5.1  SYSTEMS  NOT  JUST  SOFTW  ARE. 

The  overall  process  of  developing  a  complex 
military  aircraft  involves  many  requirements 
being  addressed  by  many  disciplines  over  a 
very  short  period  of  time.  (In  fact,  it  is 
increasing  likely  that  the  development  time 
and  cost  must  be  reduced  below  current 
levels). 
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Each  of  the  different  disciplines  (Software 
design,  installation  management, 
aeroidynamics,  operational  analysis,  flight 
test,  airframe  design  and  manufacture  etc) 
must  integrate  together  at  key  points  during 
the  development  of  the  aircraft. 

Software  engineering  up  to  now  has  tried  to 
address  a  perceived  problem  with  the 
specification,  design,  code  and  test  of 
software.  Most  development  models  mention 
the  existence  of  other  disciplines,  however 
the  integration  aspects  are  sadly  overlooked. 
In  software  we  have  focused  on  getting 
software  productivity  up  and  software 
quality  right. 

The  resultant  SDE’s  have  allowed  us  to 
produce  bigger,  better  dataflow  diagrams, 
compile  larger  amounts  of  code  faster  and 
test  individual  lines  of  code  more  completely 
than  ever  before. 

But  what  about  the  system? 

How  do  we  ensure  that  the  information 
needed  to  produce  the  aircraft  wiring 
drawings  is  provided  in  the  timescales 
required  to  the  drawing  office  instead  of 
when  required  for  software  development? 

How  do  we  cater  for  hardware  lead  times 
which  require  implementation  information 
upfront  when  we  are  following  a  top  down 
lifecycle  model  which  postpones  such  details 
until  just  prior  to  software  design. 

How  do  we  ensure  that  the  aerodynamic 
models  being  used  by  Software  designers 
within  the  SDE  are  consistent  with  those 
used  by  airframe  engineers  and 
aerodynamics  in  their  respective  toolsets? 

As  software  becomes  a  more  important 
element  of  the  overall  System  we  are  in 
danger  of  taking  longer  to  develop  the 
software  than  to  build  an  airframe.  We  may 
even  begin  to  delay  the  production  of  the 
airframe  if  we  are  unable  to  provide  the 
necessary  integration  details  in  airframe 
development  timescales. 

For  future  aircraft  projects,  the  software 
development  model  needs  to  be  expanded  up 
to  include  its  complete  integration  with  other 
development  models.  The  selection  of  the 
appropriate  methods  and  tools  can  then  be 
made  to  ensure  that  the  required  information 
is  developed  in  time  for  the  overall  aircraft 
project,  not  just  for  software. 

5.2  INCREASING  PRODUCTIVITY. 

It  is  highly  likely  that  the  next  generation  of 
combat  aircraft  will  have  considerably  more 
software  than  EFA.  It  is  also  likely  in  a 
highly  competitive  market  place  that  the 
timescales  from  development  through  to 
production  will  be  required  to  be  less  than 
that  of  EFA.  Cost  constraints  will  mean  that 
we  will  have  to  develop  this  software  with 
relatively  fewer  engineers. 

All  these  pressures  add  up  to  a  need  for 
another  step  change  in  productivity. 


Effort  for  SDE  development  can  focus  in 
this  area  on  concepts  such  as  reuse,  rapid 
prototyping  and  automatic  code  generation 
from  requirements.  Note  that  these  are 
changes  to  the  development  models  not  just 
efficiency  improvements  within  individual 
tools. 

5.3  INCREASING  DOCUMENTATION. 

The  current  lifecycle  approaches  are  also 
likely  to  swamp  the  project  under  a  forest  of 
documentation.  There  is  a  real  need  for  the 
next  aircraft  to  be  almost  totally  paperless,  if 
not  for  management  reasons  then  purely  for 
ecological  reasons. 

Again  the  emphasis  should  switch  from  tool 
development  to  method  improvement. 
Particularly  in  the  area  of  requirement 
abstraction.  We  need  to  change  the  saying  "A 
picture  paints  a  thousand  words"  to  “A 
dataflow  diagram  automatically  creates  I, OCX) 
lines  of  optomised  code". 

Process  Improvement  documentation  must 
add  value  not  just  satisfy  standards. 

5.4  INCREASING  RELIANCE  ON 
SOFTWARE. 

As  the  use  of  software  spreads  across  all 
applications  on  aircraft  there  will  be  an 
increasing  reliance  on  the  safety  of  software. 

It  takes  considerable  effort  to  ensure  that 
software  errors  will  not  have  hazardous 
consequences.  Methods  and  tools  to  support 
Formal  specification  analysis  and  proof  of 
software  have  to  be  developed  such  that  they 
are  effective  and  practical. 

It  must  be  ensured  that  these  techniques 
when  introduced  do  not  affect  productivity 
so  dramatically  that  we  can  never  afford  to 
develop  a  new  aircraft  system. 

5.5  IMPROVING  MAINTAINABILITY. 

A  key  factor  to  ensuring  that  future  projects 
are  affordable  is  by  reducing  considerably 
the  cost  of  ownership.  Not  just  ensuring  that 
there  are  few  or  no  errors  in  the  product  but 
also  ensuring  that  there  is  sufficient  growth 
built  in  to  accommodate  the  design  changes 
that  will  happen  throughout  the  service  life 
of  the  aircraft. 

Current  practice  involves  mandated  project 
wide  languages  (Eg  Ada),  developing  around 
standard  architectures,  building  in  processor 
and  memory  growth  capabilities  and  using 
modern  modular,  top  down  design  methods. 

Adopting  much  more  modular, 
reconfigurable  Avionic  architectures  could 
significantly  increase  the  adaptability  of 
future  weapon  systems  and  would  also 
support  reuseability. 
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5.6  CONTIGUOUS  METHODS. 

Modern  software  engineering  methods  and 
tools  have  been  developed  to  try  to  eliminate 
ambiguities  in  specification  and  design 
which  would  result  in  errors  in  the  code.  A 
whole  plethora  of  different  methods  and 
approaches  have  been  developed  all  claiming 
to  be  the  best  at  solving  the  problems  of 
particular  parts  of  the  software  development 
lifecycle. 

It  is  almost  unavoidable  to  have  to  choose 
different  methods  across  the  lifecycle.  This 
introduces  the  potential  for  translation  error 
and  discontinuity  when  changing  from  one 
method  to  another. 

Integrated  compatible  methods  built  on  a 
well  understood  process  model  will  not  only 
provide  a  smooth,  error  reduced  path 
through  the  lifecycle  but  will  also  provide  a 
basis  for  automatic  generation  of  lifecycle 
products  including  code. 

5.7  STABLE  TOOLSETS. 

Once  an  aircraft  project  has  developed  and 
cleared  a  large  part  of  its  software,  it  will  be 
reluctant  to  have  to  rewrite  or  reclear  this 
software  as  a  result  of  a  software  toolset  and 
host  operating  system  change.  The  most 
obvious  tool  which  can  cause  such  an  effect 
is  the  compiler. 

The  project  must  make  a  trade  off  between 
tracking  the  technology  changes  triggered  by 
changes  in  the  software  tool  market  and  the 
need  for  stability  during  the  development 
programme  and  on  into  maintenance. 

Again  this  is  an  area  where  the  development 
of  software  tools  is  constraining  the  very 
projects  that  they  have  been  developed  to 
support. 

5.8  MULTINATIONAL  COLLABORATION. 

Future  projects  are  very  likely  to  be  based 
around  some  form  of  multinational 
collaboration.  Companies  in  Europe  are  each 
investing  in  particular  software  development 
strategies  based  on  the  current  method  and 
tool  market  place.  These  strategies  will  set 
the  nature  of  that  company’s  tool 
procurement  and  staff  development 
programmes. 

When  a  collaborative  project  begins  the 
partners  must  be  able  to  work  together 
choose  an  integrated  SDE  possibly 
compromising  significantly  on  their  chosen 
strategy  and  causing  a  significant  amount  of 
new  tool  procurement  and  staff  training. 

If  there  was  an  industry  standard  SDE 
adopted  by  the  majority  of  European 
aerospace  companies  or  a  framework  for 
interchange  then  this  would  facilitate  much 
closer  collaboration  on  software 
development. 


5.9  METRICS. 

It  is  a  fundamental  quality  aim  to  have  a 
repeatable,  well  measured,  development 
process.  This  enables  sound  estimation, 
visibility  and  provides  targets  for  sensible 
process  improvement. 

However  in  multinational  projects  each 
company  as  well  as  being  a  collaborator  in  a 
particular  project  is  possibly  a  competitor  in 
other  projects.  This  makes  it  extremely 
difficult  to  share  sensitive  metric 
information  (Eg  productivity  and  quality 
levels).  However  these  very  metrics  are 
essential  to  be  able  to  effectively  manage  the 
project. 

A  metrication  system  established  for  such 
projects  must  either  be  based  around  agreed 
commercially,  protective  contracts  or  by  a 
process  of  gathering  the  metrics  without 
being  able  to  attribute  them  to  any  particular 
company.  These  metrics  could  also  be 
published  to  enable  the  method  and  tool 
developers  to  understand  the  real  problems 
of  software  development. 

6  CONCLUSIONS. 

The  EFA  SDE  marks  a  significant  step  change 
in  productivity  from  that  of  previous  BAe 
projects.  A  similar  step  change  will  be 
necessary  to  manage  the  next  generation  of 
military  combat  aircraft. 

In  the  future  software  development  has  to  be 
considered  as  a  process  within  an  overall 
framework  of  Aircraft  development.  Software 
methods  and  tools  should  be  developed  to 
fully  support  this. 

The  issues  raised  in  this  paper  are  being 
addressed  in  forums  across  Europe  and  the 
United  States  however,  progress  has  to  be 
made  to  ensure  that  the  needs  of  the  next 
large  military  aircraft  programme  are  fully 
satisfied  prior  to  the  start  of  its  development. 
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Figure  3;  EFA  Software  Development  Lifecycle. 
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Discussion 


Question  W.  ROYCE 

Can  you  support  contiguous  operation  in  which  object-oriented  software  building  is  done  side-by-side  with  procedural 
(i.e.  functknal)  software  buiktog?  What  are  the  problems? 

Reply 

In  having  a  mixed  method  approach,  which  is  feasible,  the  main  problem  is  of  traceaMlity  aocross  method  boundaries. 
For  instance,  data  is  rqtresented  centrally  in  0(X>  but  distributed  in  functknal  decomposition.  In  foUowing  such  an 
approath,  a  lot  of  effort  will  be  expended  mapping  from  one  structure  to  another. 

A  contiguous  method  would  eliminate  this  problem.  Currently,  contiguous  methods  do  not  appear  to  be  being  researched 
seiiottsly. 

Question  D.  NAIRN 

Are  you  not  barking  up  the  wrong  tree  in  focusing  on  the  tools?  Tools  are  a  means  to  an  eixl.  If  you  focus  on  an 
engineering  description,  then  your  information  is  not  being  driven  by  the  to(ris/bost  computer.  (There  is  no  fundamental 
reason  to  have  more  than  one  type  of  database,  and  more  than  one  gr^rhics  editor,  etc,  in  the  entire  environment). 

Reply 

I  agree  that  the  notation  the  design  should  be  independent  of  the  tools.  Unfortunately,  this  was  not  the  case  during 
EFA  SI£  selection.  We  use  CORE/H(XX)  and  are  tied  to  those  to(^.  Howevn,  the  problem  I  refered  to  in  the  paper  is 
maiiily  conoemed  with  changes  to  target  corrqniters  occurring  during  development  which  may  result  in  unnecessary 
retest  due  to  the  effect  of  the  compiler  diange  on  code  when  re-compiling  Eton  existing  librsay's. 

To  change  now  from  our  current  toolset  to  a  new  generic  notation  is  possible,  but  may  be  too  costly  and  take  too  long  in 
the  development  programme. 
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1.  SOMMAIRE 

Les  travaux  mends  dans  le  cadre  du  projet  MODULOR 
se  sont  inidressds  It  la  spdcirication  ei  la  mise  en  oeuvre 
d'une  machine  massivemeni  paralldle  modulaire  et 
reconfigurable  dynamiquement,  ainsi  qu‘d  la  mise  en 
oeuvre  des  outils  logiciels  ndcessaires  pour 
I'exploitation  des  possibilitds  de  reconfiguration  lors  du 
ddveloppement  d'une  application  paralldle.  La 
reconfiguration  de  raichitecture  a  dtd  diudide  tout  d'abord 
sous  I'aspect  fonctionnel  qui  vise  une  adaptation 
auiomatique  de  la  topologie  d'interconnexion  pour  une 
mise  en  oeuvre  la  plus  efficace  possible  dune 
application  donnde.  L'apport  d  une  capacitd  de 
reconfiguration  de  (a  structure  d'interconnexion  pour 
assurer  la  toldrance  de  I'architecture  paralldle  aux  pannes 
des  processeurs  a  did  abordd  dans  un  second  temps. 

Ces  travaux  mcttem  en  dvidence  la  compidmeniaritd  des 
deux  types  de  reconfiguration  ("fonctionnelle "  et  "en  cas 
de  panne")  pour  ddfinir  une  architecture  assurant  un 
maximum  d'efficacitd  de  communication,  dans  un 
environnement  temps  rdel  qui  ndcessite  de  pallicr  la 
ddfaillance  de  certains  des  didments  de  la  machine. 

2.  INTRODUCTION 

Les  besoins  de  traitement  des  systdmes  informatiques  du 
fulur  (en  particulier  au  niveau  du  traitement  des  signaux 
radars,  contre-mesures,  sonars....)  ndcessiteni  (a 
ddfinition  de  machines  massivemeni  paralldles.  Les 
contraintes  de  connexion  d'un  nombre  important  de 
processeurs  de  traitement  (plusieurs  centaines). 
conduisent  h  des  architectures  du  type  rdseau  de 
processeurs  dost  la  structure  d'ini»*rconnexion 
conditionne  les  performances.  De  plus,  les  probldmes  de 
toldrance  aux  pannes,  en  particulier  des  processeurs  de 
traitement,  imposent  la  ddfinition  d'une  structure 
d'interconnexion  permettant  la  connexion  de  ressources 
de  secours . 

Dans  une  architecture  du  type  rdseau  de  processeurs 
chacun  des  processeurs  nc  dispose  que  d'un  niveau  de 
mdmoire  locale  mais  peut  communiquer  en  mode 
message  avec  les  processeurs  auxquels  il  est  relid  par 
des  liens  de  communication.  Une  telle  architecture  est 
dile  reconfigurable  dynamiquement  lorsque  la  topologie 
d'interconneximi  des  processeurs  peut  dvoluer,  au  cours 
de  I'exdcution  d'une  application,  en  fonction  des 
commandes  foumies  i  la  structure  d'interconnexion.  Les 


architectures  ^  haul  degrd  de  paraildlisme  reconfiguraUes 
prdsentent  des  caraetdristiques  inidressantes  ;  limitation 
du  nombre  de  connexions  par  processeur,  connexion 
directe  des  processeurs  communicants  (en  dviiant  des 
mdcanismes  de  routage),  adaptation  de  la  topologie  ^  un 
probldme  donnd,  prise  en  compte  de  fonctionnement  en 
mode  ddgrat^,  transparence  ct  sot^ilesse  de  raichitecture. 

Cependant  ce  concept  de  reconfiguration  de  la  structure 
d'interconnexion  d'une  architecture  du  type  rdseau  de 
processeurs  a  did  jusqu’^  prdsent  utilisd  de  deux 
manidres  relativement  inddpendantes ; 

-  d'une  part  la  reconfiguration  fonctionnelle  qui 
vise  es.sentiellcment  I'adaptation  (la  plus 
auiomatique  et  la  plus  dynamique  possible)  dc  la 
topologie  d'interconnexion  h  un  probldme  (ou  un 
sous-probldme)  donnd  1 1 1. 

•  d'autre  pan  la  reconfiguration  en  cas  de  panne  qui 
a  principalcmcnt  comme  objeciif  d'isolcr  un  didment 
ddfaillant  de  I'architecture  pour  permettre  la 
poursuite  des  traitements  en  cours  (dveniuellemcnt 
en  mode  ddgradd).  Cette  forme  de  reconfiguration  a 
dtd  plus  particulidrement  dtudide  dans  Ic  cas  des 
architectures  du  type  tableau  de  processeurs  121,(3). 

La  spdcification  et  la  mise  en  oeuvre  d'une  machine 
massivemeni  paralldle  reconfigurable  dynamiquement  se 
heune  d  plusieurs  probldmes  ; 

-  au  niveau  architectural,  il  s'agil  de  prendre  en 
compte  les  contraintes  technologiques  telles  que  la 
taille  des  commuiateurs  utilisables  pour  construire 
la  structure  d'interconnexion  reconfigurable,  le 
nombre  de  liens  de  communication  disponibles  par 
processeur,  les  moyens  de  commande  de  la  structure 
d'interconnexion. 

-  au  niveau  iogiciel,  Ic  probldme  est  d'offrir  k 
I'ulilisateur  les  outils  permettant  I'exploitation  de  la 
reconfiguration  de  la  topologie  d'interconnexion 
aussi  bien  pour  des  raisons  d'efficacitd  que  de 
toldrance  aux  pannes. 

3.  ARCHITECTURE  RECONFIGURABLE 

La  connexion  de  I'ensemhle  des  liens  de  communication 
de  lous  les  processeurs  d'une  architecture  parallele  sur 
un  commutatcur  unique  est  rarement  possible  dds  que  le 
nombre  de  processeurs  devieni  important  (meme  d^  le 
cas  de  liens  dc  communication  sdries).  Malgrd  les 
dvolutions  technologiques  prdvisibles,  se  pose  alors  le 
probldme  de  ddfinition  d'un  rdseau  d'interconnexion  dil  It 
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Plages  qui  pr^senie  I'inconv^nient  d'un  temps  de 
transfert  plus  important.  La  solution  quo  nous  avons 
rcienue  consistc  k  b^neficier  au  maximum  dc  la  localiui 
des  cumitiunicaiions  et  s'appuie  sur  une  structure 
d'intea'onncxion  modulaiie. 

Line  premiere  idde  consistc  a  assiKier  un  cominuiaieur  a 
chaque  type  de  liens  des  processeurs  (Nord,  Sud,  Est, 
Quest,  dans  le  cas  d'un  processeur  disposant  de  quatre 
hens  dc  communication  s^rie).  Cette  hypoiMse  permet 
de  diviser  la  complexity  dc  chacun  des  commulalcurs  par 
le  nombre  de  liens  de  communication  d'un  processeur. 
Ellc  conduit  done  a  la  dyfinition  d’un  module  de 
I'architecture  qui  permet  de  connecter  localcmcnt  un 
nombre  de  processeurs  ygal  au  maximum  a  la  taillc  des 
commutatcurs  (comme  rcpryseniy  figure  I ). 


Future  I  :  architecture  d'un  module 

Une  seconde  idee  consistc  a  definir,  de  manicrc 
recursive,  un  ryseau  permettant  I'intcrconnexion  dc  icis 
modules  (comme  schymatisy  figure  2).  Un  certain 
nombre  de  liens  de  communication  est  alors  ryservy  sur 
chaque  ryseau  interne  a  un  module  pour  la 
communication  inter-modules. 


Figure  2 :  architecture  multi-modules 


L'architecture  ainsi  dyfinic  est  une  architecture 
modulaire,  composye  d'un  certain  nombre  de  modules 
rcliys  entre  cux  par  une  structure  d' interconnexion 
rcconfigurable.  chaque  miMlute  est  constituy  d'un 
ensemble  de  proces.seurs  totalement  connectys  par  une 
structure  interne  ygalcment  rcconfigurable.  Un  lien  de 
communication  entre  deux  processeurs  est  done  ytabli 
via  Ic  ryseau  intra-module  uniquement  si  Ics  deux 
priKCsseurs  sont  situys  sur  le  mcme  module.  Le  ryseau 
mter-mtxiules  n'est  nyccssairc  que  dans  Ic  cas  oil  les 
deux  processeurs  communicants  sont  situys  sur  deux 
moduks  diffyrents  (4). 

Cette  architecture  peut  etre  caracteri.sye  par  les  quatre 
paramytres  suivants: 

-  M  ;  nombre  de  modules. 

-  N  :  nombre  de  processeurs  par  module. 

-  L  :  nombre  de  liens  par  processeurs. 

-  S  :  nombre  dc  liens  dc  chaque  commuiateur 

interne  ryserv-y  pour  la  communicatHin  mtcr-nuxlule. 

Cependani  plusieurs  nuxles  dc  connexion  des  diffyrents 
commutatcurs  internes  et  extemes  a  un  module  sont 
envisageaWcs.  Nous  verrons  plus  loin  que  la  conception 
des  structures  d'imcrconnexion  intra  et  inter-modules  a 
yty  validye  par  la  dymonstraiion  dc  la  capacity  de 
l'architecture  ainsi  dyfinic  ^  supporter  une  application 
rcconfiguniblc. 

4.  APPLICATION  RKCONFIGl  RABLK 

La  misc  cn  oeuvre  d'unc  application  sur  une  telle 
architecture  parallcic  rcconfigurable  nyccssiie  des  ouuls 
spycifiques  si  Ton  veut  utiliscr  pictnement  les 
possibilites  dc  reconfiguration  dynamique  dc  la 
topologie  d'intcrconncxion.  Nous  nous  intyrcsscrons 
dans  un  premier  temps  a  I'aspect  reconfiguration 
fonctionncllc,  e’est  ^  dire  ii  la  recherche  d  une  (ou 
plusieurs)  topologic(s)  d'intcrconncxion  adaptyc(s)  aux 
besoins  de  communication  dc  I'appiication.  Nous 
supposcrons  que  le  dycoupage  de  I’appiication  en 
modules  paralldlcs  a  dyjii  yuf  cffcciuy  (comme  pour  une 
mise  en  oeuvre  sur  une  architecture  ii  topologie 
d'intcrconncxion  fixe). 

II  semble  aciuellcment  irryaliste  de  vouloir  dytermincr 
aulomatiquement  les  instants  ou  la  topologie 
d'intcrconncxion  devrait  ctre  modifiye.  L’hypothfese 
retenue  consistc  d  dycrire  une  application  paraliyie 
rcconfigurable  comme  une  succession  de  phases 
algorithmiqucs,  pouvant  prysenter  dcs  besoins  de 
communication  diffyrents.  Ces  pha.ses  seront  syparyes 
par  dcs  points  dc  reconfiguration  cxplicitemcnt 
introduits  par  le  programmeur.  Ce  dernier  dycrira 
cgalcmcnt  I'cnchaincmcnt  souhaity  de  ces  diffyrenies 
phases  (qui  pcui  dypendre  dcs  ry.sultaLs  dc  iraitemenLs). 

Une  phase  algorithmiquc  donnee  peut  etre  alors  dycrite 
sans  connaissance  dc  l'architecture  sous-jacente.  Nous 
supposcrons  que  I’appiication  peut  6irc  reprysentye  sous 
forme  de  processus  communiquant  en  mode  message  (en 
utilisant,  par  exemple,  un  moddle  de  programmation 
concurrente  de  type  CSP ;  "Communicating  Sequential 
Processes"  [10)  ).  On  appelcra  processus  I'unity 
d'allocation  de  traitements  sur  un  processeur  de 
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ratchitecture  (ce  qui  n'exclui  pas  une  granuiahi^  phis 
fine  de  ptwessus  exfeuits  en  quasi-paraJKIisme  sur  un 
piDcesseur).  Chaque  phase  peui  done  ivn  rcprtsenife  par 
un  graphe  oil  un  noeiid  ~pr£senic  un  processus  et  un  arc 
(orieniii)  un  ben  de  omunkalion  l^ique  reliant  deux 
processus  (co«r  iionirj  figure  3). 

Le  prcM  ..c  de  ikveloppement  d  une  application 
reconfigurable  pone  done  sur  I'analyse  dcs  difKrents 
graphes  de  communication  de  I'application  et  sur  la 
determination  automatique  de  la  topologie  la  mieux 
adapt6e  k  chacune  des  phases  de  ceue  application.  Nous 
avons  fait  le  choix  d'un  interface  graphique  pour  la 
descripuon  des  differents  graphes  de  communicauon  de 
I'application. 


Premiere  phase 


Troisieme  phase 


Lcs  outils  dc  devcioppement  qui  onl  etc  dcfinis 
component  principalcmcni  trois  modules  [4|: 

-  un  interface  graphique  permettant  la  description 
d'unc  application  reconfigurable  exteme  de  graphes 
de  processus  communiquant  en  mode  message. 


-  un  outil  de  placement  de  graphes  de  processus  sur 
un  r6ieau  de  processeurs  reconfigurable  qui  conduit  h 
la  determination  de  la  topologie  d'inierconnexion 
n^essaire  et  des  commandes  correspondantes  des 
difKrents  commutaieurs, 

-  un  logicici  de  g^n^ration  de  code  qui  assure  les 
mteanismes  dc  synchronisation  n^essaires  avant 
lout  changemeni  de  la  uipologie  d'inierconnexion. 
Le  code  ginirt  pour  ceite  synchronisation  se  situe 
au  n.veau  des  processeurs.  mais  £galemcnt  au  niveau 
de  la  machine  hdtc  qui  gire  I'envoi  des  commandes 
aux  commutaieurs  pour  rdaliser  les  changements  de 
topologie  et  renchainemeni  des  diffdrenies  phases. 

5.  PLACEMENT  D‘LNE  APPLICATION 
RKCUNEIOLiRABLE 

Les  ouiils  de  d^veluppcmeni  qui  viennent  d'etre 
pr^seiiks  inclueni  une  dtape  importante  de  placement 
des  graphes  de  pnx:es,sus  assixri^s  au  differentes  phases 
de  I'application  reconfigurable  sur  I'archiiccture  multi- 
modules  propose.'.  La  modularite  dc  ceue  architecture 
induit  en  effci  des  problCmcs  suppldmcniaires  dus  i  la 
limitation  du  nombre  dc  liens  de  communication  intcr- 
modules. 

Pour  simplifier  rexpose,  nous  supposerons  que  le 
nombre  dc  processus  de  chaque  phase  cst  infirieur  ou 
(5gal  au  nombre  de  processeurs  dc  I'archiieciurc  et  que  le 
degrd  dc  connectivity  dc  chaque  processus  est  infiSricur 
ou  egal  au  nombre  dc  liens  physiques  disponibles  sur 
chacun  des  proccs,scurs.  Ces  hypothdscs  sur  le  graphe 
initial  occultent  deux  probicmes  complexes  que  nous  nc 
dcvclopperons  pas : 

■  le  premier  cst  cclui  de  la  conuaction  d'un  graphe 
dont  le  nombre  dc  privcssus  dypas.se  le  nombre  de 
processeurs  disponibles.  Cc  probldme  dc  contracuon 
qui  vise  Ic  rcgrtHipemcnt  de  processus  sur  le  rndme 
processcur  est  yquivalent  au  probiyme  de 
partitionncmcni  que  nous  yvoquerons  plus  loin  |8), 

-  le  second  cst  cclui  dc  la  vansformation  d'un  graphe 
de  processus  dont  le  degry  de  connectivity  est 
supyrieur  au  nombre  de  hens  disponibles  sur  un 
processcur.  Ce  probldmc  peui  nyccssiter  la  cryaiion 
dc  proccs,sus  dc  multipicxagc  permettant  de  gyrer  le 
partage  d'un  rndme  lien  physique  par  plusicurs  liens 
logiques. 

Lin  algorithmc  dc  placement  d'unc  application  distribuye 
a  pour  objcciif  d'allouer  lcs  processus  qui  constituent 
cette  application  sur  lcs  processeurs  disponibles  en 
assurant  lcs  communications  ndeessaires.  Compte  tenu 
des  hypoUidscs  qui  viennent  d'Slre  rappcides  et  du  fait 
que  lous  les  processeurs  sont  banaiisys,  le  probldme  de 
placement  Ju  graphe  de  processus  associd  <i  chaque 
phase  sur  un  ici  rdseau  de  processeurs  reconfigurable  se 
ramdne  ^  la  dyierminaiion  dcs  liens  dc  communication 
qui  doivent  6irc  dtablis  cnire  processeurs  en  foncuon  des 
processus  qu'ils  exycutent  |9|.  Apits  analyse  du  graphe 
de  communication,  >1  s'agit  bicn  de  dyterminer  la 
topologie  d'intcrconnexion  adaptde  ^  chaque  pha.se  de 
I'application. 

Le  placement  d'un  graphe  dc  proces.sus  sur  I'architecture 
multi-modules  ddfinie  pose  deux  probldmcs  [6] ; 
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agu  d'une  pan  de  paniiionner  le  graptie  global 
wu  sous-graf^s  faiblemcni  inierconncciis  de  leile 
mani&re  que  les  comiainics  de  nombre  de  modules  et 
de  connexion  enire  modules  puisseni  iire  satisfaites 
(voir  figure  4), 

-  il  taut  assurer  d'autre  pan  que  chacun  des  sous- 
grapbes  obienus  puisse  itre  alloui  sur  un  module  de 
rarchiieciure.  c'est  ^  dire  que  les  liaisons  inira  et 
inter-modules  puisscnt  Stre  dtablies  (comme 
i«pr6>cnt^  figure  5). 


G1 


Module  1  Module  2 


Module  4  Module  3 


(N=4.  M=4,L=4,S=1) 

Des  heuristiques  dc  panitionnement  de  graphes  oni  done 
etc  d^vcloppees.  Elies  s'appuicnt  sur  une  notion 
d'affinitd  enirc  processus  qui  permet  de  permet  dc 
constituer  le  nombre  de  partitions  souhalte  en 
minimisant  les  communications  entre  partitions  (prise 
en  compte  de  la  contrainte  des  liens  de  communication 
extemes  a  un  module  L*S).  Ccs  heuristiques  oni  etc 
validdcs  sur  des  graphes  fortement  conneci^s 
(hypertores..)  el  soni  d'une  complexite  polynomialc 
infcricure  a  cellc  d’auues  heuristiques  connues. 


D'autre  pan  la  conception  des  deux  r^seaux 
d'inierconnexion  a  6i£  giudiie  par  la  demonstration  de  la 
capacity  de  i'architeciure  ainsi  definie  it  supporter  le 
pl^ement  de  toute  application  codec  en  termes  de 
processus  communiquant  qui  soit  partitionnable. 

Ainsi,  le  placement  d'un  graphe  de  processus  sur  un 
module  de  I'architecture  impose  une  hypoihese 
supplemeniaire  qui  constsie  a  associer  deux  a  ^ux  les 
commuiateurs  d'un  module.  Dans  le  cas  d'un  processeur 
a  4  liens,  on  disposera  d'un  reseau  Nord/Sud  et  d'un 
reseau  Est/Ouest  (si  le  lien  Out  du  lien  bi-directionnel 
est  connccte  au  reseau  Nord.le  lien  In  est  connecie  au 
reseau  Sud,  comme  represente  figure  6). 

Dc  memc,  le  placement  de  tout  graphe  panuionnable 
n  est  garanu  que  si  le  reseau  mter-modules  est  constitue 
de  telle  mameie  qu'un  commuiaieur  exiemc  suppone  les 
liens  cxtcrncs  d’un  rang  donne  dans  chacune  des 
directions  de  connexion  provenani  de  tous  les  modules 
(comme  mpresente  sur  la  figure  6). 

Compte  tenu  dc  ccs  deux  hypotheses  aahiteciuralcs,  il  a 
cie  demontre  qu'il  est  possible  de  placer  tout  graphe  dc 
priKCssus  partitionnable  verifiant  les  propriitifs 
cnoncees  plus  haul  sur  rarchiieciure  multi-modules  [61. 


Les  deux  niveaux  dc  rescaux  d'inierconnexion  peuvent 
mis  en  oeuvre  a  I'aide  de  commutatcurs  clemcniaires  de 
laillc  raisonnabic  (5| : 

-  un  rdscau  intra-module  est  compost  dc  L 
commutatcurs  internes  reliant  un  type  des  L  liens  de 
communications  dcs  N  processeurs  d'un  module.  Sur 
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chacun  des  L  commutaieurs  intemes  d'un  module  S 
ports  sont  r^serv^s  pour  la  communication  inter¬ 
modules.  Un  commuiaieur  interne  doit  done  pouvoir 
commuter,  au  minimum,  N-fS  ports  d'enir6e  vers 
N-fS  ports  de  sortie. 

-  le  rdseau  inter-module  retenu  est  composd  de  2*S 
commutateurs  qui  relient  chacun  L/2  liens  de  meme 
rang  provenant  des  M  modules.  Chacun  de  ces 
commutateurs  doit  done  pouvoir  commuter  M*L/2 
ports  d'entrde  vers  M*Ly2  ports  de  sortie. 

6.  RECONFIGURATION  ET  TOLERANCE 
AUX  PANNES 

Pour  augmenter  la  disponibilitd  du  systi^me,  nous  nous 
intdresserons  surtout  aux  techniques  de  resolution  de 
pannes  mat6rielles,  pannes  auxquelles  on  peut  parfois 
assimiler  des  pannes  logicielles  (par  exemple  les  pannes 
qui  se  Iraduisent  par  un  silence  du  processeur  defaillant). 

Une  architecture  paralieie  peut  assurer  une  redondance 
statique  et  le  masquage  d'erreur  (3|.  Cette  technique  ddjii 
dprouv^e  pour  les  traitements  sequentiels  est  souvenl 
utilisee  dans  les  syst^mes  embarques.  La  replication  des 
uaiiements  et  des  mecanismes  de  vote  majoritaire  .sont 
generalement  mis  en  oeuvre.  Le  modeie  TMR  (“Triple 
Modular  Redundant”)  est  un  exemple  de  la  ciasse  des 
mdthodes  de  programmation  en  N  versions.  Ces 
techniques  integrent  des  mecanismes  sophistiquds  pour 
traiter  les  probiemes  de  communication  y  compris  dans 
le  processus  de  vote  (protocoles  d'agrement  byzantin). 

Les  mecanismes  de  redondance  dynamique,  peuvent  eire 
mis  en  oeuvre  sur  une  architecture  reconilgurable.  11s 
permettent  egalement  de  garantir  la  continuite  des 
services  si  des  cycles  de  reprise  sont  admis.  Les 
principes  sont  la  detection  d'erreur,  les  techniques 
permettant  de  reperer  leiement  defectueux,  les 
mecanismes  permettant  la  reprise  . 

La  redondance  dynamique  maierielle  qui  est  visee  repose 
done  sur  la  possibilite  de  reconfiguration  de  la  lopologie 
d'interconnexion  permettant  le  remplacement  de 
processeurs  defaillants  par  des  processeurs  de  secours. 
La  connexion  de  processeurs  addilionnels  sur  chaque 
module  de  rarchitecture,  permet  de  remplacer  n'importe 
quel  processeur  ddfaillant  d'un  module.  La  redondance 
mat^rielle  peut  Egalement  etre  prise  en  compte  au 
niveau  d'un  module  (connexion  d'un  module 
additionnel).  Nous  n^gligerons  dans  un  premier  temps 
les  pannes  des  r^seaux  d'interconnexion  ou  plus 
exactement  nous  supposerons  que  les  moyens  de 
communication  peuvent  etre  redoubles  (7). 

Compte  tenu  des  capacii6s  de  reconfiguration  de 
rarchitecture,  la  mise  en  oeuvre  de  techniques  de 
redondance  dynamique  peut  etre  r6ali.s£e  par  logiciel.  Les 
mecanismes  de  detection  de  pannes  reposent  sur  la 
notion  de  phase.  Une  phase  correspond  ^  I'execution 
d'un  graphe  de  processus  communicants  et  son 
execution  est  automatiquement  precedee  par  un 
algorithme  de  synchronisation  de  debut  de  phase  el 
suivie  par  un  algorithme  de  synchronisation  de  fin  de 
phase.  Si  nous  supposons  que  la  panne  d'un  processeur 


lors  de  I'execution  d'une  phase  conduit  ^  un  interblocage 
(hypothese  du  processeur  silencieux  en  cas  de  panne).  II 
est  passible  de  demonusr  que  cet  interblocage  se  produira 
quelque  soit  I'instant  de  la  panne:  debut  de  phase,  code 
algoriihmique,  fm  de  phase.  En  particulier  les  echanges 
necessaires  pour  la  synchronisation  de  fin  de  phase 
conduiront  au  blocage  meme  si  les  processus  de  la 
phase  algorithmique  ne  communiquent  pas. 

Les  mecanismes  mis  en  place  permettent 
successivement : 

-  de  detecter  le  blocage  des  processus  pendant 
I'execution  de  la  phase, 

-  de  debloquer  les  processus  en  attente  sur  un  ou 
plusieurs  liens  de  communication. 

-  d'attendre  la  terminaison  des  processus  bloques 
(synchronisation  de  fin  de  phase  minimale)  avant 
d'enchainer  avec  la  phase  de  diagnostic. 

Les  mecanismes  de  detection  du  blocage  des  processus 
(genere  par  une  communication  qui  ne  se  termine  pas), 
reposent  sur  I'introduction  d'un  deiai  d'execution 
maximal  pour  chaque  phase.  Le  calcul  de  ce  deiai  peut 
etre  realise  h  I'aide  de  mesures  d'cxecutions  des 
differentes  phases  dans  un  environnement  exempt  de 
pannes.  Le  code  des  mecanismes  de  detection  du  bk^ge 
repose  d'une  part  sur  I'utilisation  des  horloges  et  de 
mecanismes  de  detection  d'anomalies  de  uansmission. 
Des  mecanismes  de  re-iniiialisation  dcs  canaux  de 
communication  sont  egalement  necessaires. 

La  phase  de  diagnostic  est  gcree  comme  une  phase 
additionnclle.  Au  cours  de  cette  phase,  le  superviscur, 
e'est  itdirc  la  machine  hdte  etablira  un  dialogue  avec  les 
differents  processeurs.  La  panne  d'un  lien  de 
communication  sera  consideree  comme  la  panne  totale 
du  processeur,  car  il  est  a  priori  necessaire  de  disposer 
d'une  connectivity  totale  pour  assurer  rex6cution  du 
code  usager.  Cette  phase  de  diagnostic  met  ii  jour  des 
tables  d'ytat  du  systdme,  utiles  pour  rex6cution  des 
phases  suivantes,  mais  Egalement  pour  la  maintenance. 

La  reconfiguration  de  I'architecturc  consisic  i  remplacer 
le  processeur  dyfaillant  par  un  processeur  de  secours.  le 
nombre  de  processeurs  de  secours  d6termine  le  nombre 
de  pannes  pouvant  Itre  prise  en  compte  lors  de 
I'exycution  d'une  application.  Le  principe  de  mise  en 
oeuvre  est  celui  de  la  reconfiguration  fonctionnelle  dans 
la  mesure  ou  tous  les  processeurs  (de  traitement  et  de 
secours)  sont  des  processeurs  banalisys  ; 

-  le  processeur  de  secours,  d^j^  possesseur  du  code 
de  I'application  re^oit  I'identity  logique  de  la  tache  i 
assurer, 

-  les  commandes  du  reseau  interne  au  module  sont 
appliqu^cs  de  telle  manifere  que  le  processeur  de 
secours  vienne  remplacer  le  processeur  dyfaillant 
dans  la  topologie, 

-  les  commandes  des  r^seaux  externes  sont 
conservtes. 

II  est  important  de  noter  que  tout  partitionnement  et 
placement  dynamiques  sont  dearths.  II  n'est  pas  envisage 
de  fonctionnement  en  mode  d^grady  sur  un  nombre 
restreint  de  processeurs.  La  notion  classique  de  point  de 
reprise,  s'applique  pour  reprendre  le  traitement  de 
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I'application  en  cours.  Une  r6-iniiialisation  du  contexie 
au  (kbut  de  la  phase  counuue  peimet  de  confondie  point 
de  reprise  ei  point  de  synchronisation  de  d^but  de  phase. 
Cette  strat^gie  suppose  qu'une  phase  de  sauvegarde  du 
contexte  des  processus  soit  ins^rie  apr^s  chaque 
terminaison  normale  de  phase.  Cette  sauvegarde 
distribute  est  effectute  par  un  systtme  de  voisinage  et 
est  bien  sdr  elle  mime  prottgte  contre  les  pannes.  La 
phase,  symttfique,  de  restaurauon  des  contextes  est 
mise  en  oeuvre,  avant  la  rt-extcuiion  de  toute  phase 
interrompue. 

L’environnement  de  dtveloppement  ddcrit  prtctdemmem 
a  €l6  modifit  pour  mettre  les  mtcanismes  assurant  la 
toltrance  aux  pannes  de  processeur.  Les  modincations 
apporttes  it  la  chaine  de  dtveloppement  d'applications 
reconfigurables  sont  relativement  minimes.  L'usager 
doit  annoter  chaque  phase  d'une  durte  d'extcution 
maximale,  la  structuration  de  I'application  en  phase 
peut  cependant  ttre  revue  pour  optimiser  le  dtroulement 
de  I'ex^ution  du  programme  en  cas  de  panne.  II  peut 
ttre  en  effet  souhaitable  de  rajouter  des  points  de 
synchronisation  (de  reprise)  dans  te  cas  d'une  phase  trop 
longue  pour  obtenir  un  ensemble  de  phases  de  grain 
plus  fin. 

Le  code  correspondant  aux  mtcanismes  de  loltrance  aux 
pannes  est  instrt  automatiquement  par  le  gtntrateur  de 
code. 

7.  maquettage  et  validation 

Une  maquette  fonctionnelle  de  I'architecture  sptcifite  a 
tit  rtali^  ^  partir  de  composants  standard  INMOS  :  le 
Transputer  T800  qui  dispose  de  4  liens  de 
communication  et  le  commutateur  crossbar  C004  qui 
permet  de  connecter  32  voies  d  entrte  sur  32  voies  de 
sortie.  Les  valeurs  des  paramttres  retenues  pour  ce 
maquettage  sont :  M=4,  N=20,  L=4,  S=8. 

L'architecture  permet  de  btntficier  de  la  localitt  de 
connexion  des  liens  de  communication  des  processeurs 
au  niveau  d'un  module  et  de  minimiser  le  nombre  de 
connexions  inter-modules  L'inttgration  d'une  telle 
architecture  peut  done  ttre  rtaliste  de  manitre 
relativement  simple : 

-  des  cartes  mtres  assurent  pour  chacun  des  modules 

I'impltmeniation  du  rtseau  intra-module, 

-  des  cartes  filles  sur  lesquelles  se  trouvent  les 

processeurs  et  leur  mtmoire  viennent  s'enficher  sur 

les  cartes  mtres, 

-  une  carte  fond  de  panier  rtalise  I'interconnexion 

des  cartes  mtres  en  impitmentant  le  rtseau  inter¬ 
modules. 

Cette  maquette  a  permis  une  validation  en  vraie 
grandeur  de  rarchitecture  multi-modules  et  de  la  chaine 
de  dtveloppement  d'applications  reconfigurables.  Ces 
outils,  tcrits  en  langage  C,  utilisent  pour  la  partie 
graphique  la  bibliothtque  GMR2D  disponible  sur  les 
stations  de  travail  HP-Apollo.  Ils  sont  en  cours  de 
portage  sous  I'environnement  XWindow.  Les  codes  des 
processus  de  l'usager,  relits  grfice  t  I'interface  graphique 
pour  former  une  seule  application,  sont  actuellement 
tcrits  en  langage  OCCAM  [11]. 


Les  premitres  applications  mises  en  oeuvre  sur  cette 
maquette  ont  montrt  le  gain  apportt  par  I'utilisation  des 
possibilitts  de  reconfiguration  de  la  topologie 
d'inierconnexion.  Les  performances  sont  augmenttes  de 
pits  d'un  tiers  pour  certaines  applications,  par  rapoort  t 
leur  impitmentation  sur  la  mtme  architecture 
configurte  selon  une  topologie  fixe  (grille).  Ces 
rtsuliats  dtpendent  cependant  de  nombieux  paramttres : 
mattriels  utilists  d'une  part  (temps  de  reconfiguration, 
cout  de  routage...),  caraettristiques  de  I'application 
d'autre  part  (volumes  de  uansferts,  distance  et  variation 
de  communications  entre  processus...). 

Cet  environnement  de  dtveloppement,  ttendu  pour 
I'aspect  toltiance  aux  pannes,  a  ttt  validt  sur  quelques 
applications.  Les  pannes  des  processeurs  ont  ttt 
simultes  par  I'ajout  de  points  d'arret  dans  les  codes  de 
certains  processus.  Le  cout  des  mtcanismes  assurant  la 
toltrance  aux  pannes  n'a  pu  faire  I'objet  de  mesures 
fines.  II  est  actuellement  directement  lit  aux 
mtcanismes  de  sauvegarde  qui  n'ont  pas  fait  I'objet 
d'optimisations  particulitres. 

CONCLUSION 

L'ttude  a  permis  de  mettre  en  tvidence  I'apport  d'une 
structure  d'interconnexion  totalement  reconfigurable 
permettant  de  gtrer : 

-  une  reconfiguration  fonctionnelle  de  la  topologie 
d'interconnexion  tvitant  au  maximum  les 
mtcanismes  de  routage  par  une  connexion  directe  des 
processeurs  communiquant  enue  eux, 

-  une  reconfiguration  en  cas  de  panne  visant  le 
masquage  de  la  dtfaillance  d'un  ou  plusieurs 
processeurs  rendue  possible  dans  la  mesure  oil  tous 
les  processeurs  sont  banalists  et  que  dcs  processeurs 
de  secours  sont  tgalement  relits  &  cette  structure 
d'interconnexion. 

Les  travaux  prtsentts  ont  montrt  I'apport  d'une 
architecture  modulaire  pour  la  mise  en  oeuvre  d'une 
structure  d'interconnexion  reconfigurable.  Cette 
modularitt  est  tgalement  utile  pour  la  prise  en  compte 
de  mtcanisme  dc  toltrance  au  pannes. 

Cette  ttude  a  de  plus  dtmontrt  la  faisabilitt  de 
solutions  pouvant  etre  apporttes  au  niveau  logiciel 
pour  permettre,  en  function  dcs  hypothtses 
architecturales,  de  poursuivre  I'extcution  d'une 
application  aprts  dttection  d'une  anomalie  et 
reconfiguration  de  l'architecture. 

D’autres  approches  seraiem  4  envisager  pour  assurer  la 
toltrance  aux  pannes  d 'architectures  du  type  rtseau  de 
processeurs  en  paiticulier  celles  consistant  i  allier  des 
mtthodes  de  type  masquage  d'erreur  avec  des  mtthodes 
du  type  dttection  de  panne  [12]. 


Les  travaux  ments  dans  le  cadre  du  projet  MODULOR 
ont  fait  I'objet  de  contrats  DRET  (Direction  des  Etudes 
Recherches  et  Techniques  de  la  DGA)  et  sont  soutenus 
par  le  MRT  (PRC  Architectures  Nouvelles  de 
Machines)  et  la  rtgion  Midi-Pyrtntes. 
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Discussion 

Question  W.  MALA 

1 .  In  case  of  reconfiguration,  bow  will  the  software  package  be  loaded  to  the  spare  processor  under  real  time  conditions? 

2.  How  can  you  ensure,  in  case  of  a  failure,  which  data  are  still  valid  and  which  are  wrong? 

3.  What  amount  of  time  will  be  required  for  reconflguration? 

Reply 

1.  Le  logkiel  est  actuellement  charge  stadquement  sur  les  processeurs.  II  s'agit  d’un  logiciel  g6n6rique(identique  pour 
tous  les  processeurs).  Le  code  ddrould  par  un  processeur  d^nd  de  son  numdro  (fidentifleation.  Les  processeurs  de 
secours  disposent  de  ce  code  et  repiennent  les  numdros  des  processeurs  ddfaillants. 

2.  Les  donndes  sont  sauvegarddes  oi  fin  de  phase  (notion  de  sauvegade  de  contexte).  Dans  le  cas  d'une  ddfaillance  d'un 
processeur,  I'exdcudon  de  la  phase  courante  est  reprise  h  partir  des  donndes  sauvegarddes  (h  la  fin  de  la  phase 
prdeddente).  Un  processeur  de  secours  doit  pouvoir  acedder  aux  donndes  qui  avaient  dtd  sauvegarddes  par  le  processeur 
qui  vient  de  tomber  en  panne.  Des  mdeanismes  de  duplication  des  sauvegardes  sur  des  processeurs  voisins  sont  mis  en 
oeuvre. 

3.  Temps  de  commande  des  rdseaux  d'intmoonnexion  (avec  la  technoiogie  utilisde)  •>  10  ps. 

Temps  de  reconfiguration,  incluant  les  mdeanismes  de  synchronisation  par  dchange  de  messages  (avec  les  processeurs 
T  8(X)  et  des  liens  de  communication  h  10  Mbits/s)  •1,5  ms. 
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SUMMARY 

AIMS  is  a  European  industrial  research  project 
which  focuses  on  the  process  for  the  development 
and  maintenance  of  Embedded  Computing  Systems 
which  are  an  integral  part  of  high  technology 
aerospace  products.  It  is  a  user  driven  project  which 
uses  a  problem  oriented  approach  to  solve  the  diffi¬ 
culties  encountered  in  the  production  of  such 
systems.  The  relevance  of  the  proposed  solutions  to 
the  problems  is  ensured  by  involving  aerospace  en¬ 
gineers,  who  work  on  the  development  and  mainten¬ 
ance  of  embedded  systems.  This  involvement 
ensures  that  new  technologies,  or  improved 
practices,  can  be  rapidly  introduced  into  operational 
projects. 

USTQF  SYMBOLS 

AIMS  Aerospace  Intelligent  Management  and  de¬ 
velopment  environment  for  embedded 
Systems 
ALN  Alenia 
AS  Aerospatiale 
A340  Airbus  340 
BAe  British  Aerospace 
EC  Eurocopter 

ECS  Embedded  Computing  System 
EFA  European  Fighter  Aircraft 

1  INTRQDUCnQN 

The  AIMS  Project  is  a  unique  Project  within  the  EU¬ 
REKA  programme  which  addresses  the  problems 
companies  have  in  developing  and  maintaining  the 
complex  embedded  systems  found  within  many 
aerospace  products.  The  AIMS  Project  is  looking  to 
improve  the  development  and  maintenaiKe  process 
for  embedded  systems  to  maintain  the  competitive 
advantage  the  European  Aerospace  industry  has 
achieved  through  collaborative  projects.  Its  area  of 
application  has  been  recognised  by  the  EUREKA  in¬ 
itiative  as  being  of  great  importance  to  the  future 
success  of  the  European  aerospace  industry. 

The  aim  of  this  paper  is  to  present  an  overall  view  of 
the  AIMS  Project  and  a  description  of  the  technical 
approach  that  has  been  adopted  for  the  current  phase 
of  the  Project. 


The  background  to  AIMS  is  described  along  with  the 
organisation  of  the  Project.  The  Project’s  overall  ob¬ 
jectives  and  strategy  are  described,  which  provide  the 
context  for  the  current  phase.  A  summary  of  the 
technical  approach  is  provided  with  an  indication  of 
the  type  of  technical  work  which  is  being  undenaken. 
The  conclusion  describes  the  results  we  have 
achieved  to  date. 

2  BACKGROUND  TO  THE  AIMS  PROJECT 

High  technology  products,  such  as  aircraft, 
spacecraft,  helicopters  and  missiles  contain  increas¬ 
ingly  complex  Embedded  Systems  like  flight  control, 
avionic  and  cockpit  systems.  The  trend  within  these 
systems  is  to  develop  Embedded  Computing  Systems 
(ECSs)  that  provide  significantly  more  functionality 
without  tlK  weight  and  si/e  penalties  of  traditional 
electro-mechanical  systems.  One  of  the 
consequences  of  this  trend  is  the  rapid  growth  of  the 
software  within  ECSs  as  is  illustrated  in  figure  1. 
The  ECSs  now  account  for  at  least  one  third  of  the 
overall  cost  of  the  high  technology  aerospace 
products  and  have  a  significant  impact  on  the 
timescale  for  developing  these  products. 


Fig.  1 ;  Growth  of  on-board  SW 


Presented  at  an  AGARD  Meeting  on  ‘Aerospace  Software  Engineering  for  Advanced  Systems  Architectures',  May  1993. 
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Maiket  forces  and  political  pressures  have  compelled 
the  aerospace  companies  to  collaborate  in  a  large 
number  of  international  programmes.  Through  these 
collaborative  initiatives  such  as  Airbus,  Ariatte  and 
Tornado,  the  European  aerospace  industry  has 
obtained  a  competitive  advantage  in  the  world 
market.  This  success  has  led  to  an  increasing  number 
of  collaborative  initiatives  such  as  EFA  2000  (Euro¬ 
pean  Fighter  Aircraft),  ATR  (regional  transport 
planes),  Columbus  (orbiting  space  station)  and  Tiger 
(combat  helicopter).  It  is  envisaged  that  the  vast  ma¬ 
jority  of  all  future  aerospace  projects  will  be  collabo¬ 
rative. 

It  is  a  major  challenge  for  the  European  aerospace  in¬ 
dustry  working  in  collaborative  projects  to  develop 
the  complex  ECSs  on  time  arHl  within  budget.  The 
need  in  the  future  for  even  more  complex  systems 
will  require  more  effective  collaboration  to  share  the 
high  development  costs. 

Within  this  context,  three  major  European  aerospace 
companies,  from  now  on  called  Partner  Companies, 
Aerospatiale  (France),  Alenia  (Italy)  and  British 
Aerospace  (United  Kingdom),  decided  to  cooperate 
through  a  research  project  called  AIMS. 

The  Partner  Companies  are  engaged  in  all  phases  of 
design,  production  and  maintenance  of  a  large 
variety  of  sophisticated  aerospace  products  and  have 
substantial  experience  in  the  production  of  the  Em¬ 
bedded  Computing  Systems  installed  within  these 
products. 

3  PROJECT  OBJECTIVES  AND  STRATEGY 

The  overall  objective  of  the  Project  is  to: 

Reduce  the  cost  of  collaboratively  developing 
and  maintaining  ECSs  by  enhancing  produc¬ 
tivity.  stabilising  timescales  and  improving 
cooperation,  while  ensuring  the  required 
quality  levels  are  maintained. 

Therefore  the  focus  of  AIMS  is  on  improving  the 
ECS  development  and  maintenatKe  process  and  not 
on  any  particular  ECS  product.  Neither  is  it  targeted 
to  one  specific  aerospace  project  but  it  is  intended  to 
bring  long  term  beneftts  to  a  large  number  of  future 
projects. 

The  AIMS  Project  mission  is  to  obtain  agreement 
with  future  collaborative  partners  on  the  required  im¬ 
provements  to  the  ECS  development  and 
maintenance  process  to  ensure  future  projects  can 
develop  complex  ECSs  on  time  and  within  budget. 

To  support  this  mission  a  strategy  has  been 
developed  which  recognises  the  trends  within  the 
aerospace  industry: 

•  the  majority  of  future  projects  will  be 
collaborative; 


•  an  increasing  number  of  ECSs  will  be  used  to 
provide  the  increased  functionality  required  for 
future  systems; 

•  an  increasing  proportion  of  the  development  arid 
maintenance  costs  of  the  aerospace  piquets  arc 
due  to  the  ECSs. 

The  strategy  then  builds  on  the  strengths  of  the  par¬ 
ticipating  companies  and  on  their  particular  needs. 

The  strategy  recognises  that  the  current  ECS  devel¬ 
opment  process  and  its  current  use  of  methods  and 
their  supporting  tools  do  not  fully  satisfy  the  require¬ 
ments  of  the  aerospace  companies  and  will  be  unable 
to  support  the  production  of  future  aerospace 
systems.  For  the  environments  to  meet  the 
challenges  presented  by  the  rapid  growth  of 
embedded  systems,  i«w  ways  of  working  supported 
by  new  tecluiologies  must  be  found  to  enhance  their 
productivity. 

AIMS  believes  that  it  can  play  an  important  role  in 
improving  the  process  of  ECS  development  and 
maintenance;  not  by  developing  a  unique 
environment  for  developing  all  the  future  aerospace 
ECSs,  but  by: 

•  improving  and  harmonising  the  ECS  development 
and  maintenance  process; 

•  industrialising  new  emerging  technologies; 

•  defining  common  requirements  based  on  real 
problems  for  the  type  of  tools  and  support  envi¬ 
ronment  required  by  the  European  aerospace  in¬ 
dustry  and 

•  influencing  emerging  standards  which  will  have 
an  impact  on  the  support  of  the  ECS  development 
process. 

This  strategy  is  being  implemented  in  the  following 
way; 

1) The  AIMS  Project  must  first  look  at  how  the 
aerospace  companies  work  on  ECS  development 
now  and  in  the  near  future,  to  identify  the 
problems  they  experience  with  their  working 
practices  aixl  the  available  technologies.  EHffer- 
ences  and  commonalities  of  the  various  ECS  de¬ 
velopment  processes  have  to  be  identified  and 
analysed  to  prepare  the  convergence  towards  the 
AIMS  generic  ECS  development  process. 

2)  AIMS  must  then  indicate  potential  solutions  to 
the  problems  identified  above,  which  could  be 
new  techniques  or  technologies,  or  the  improve¬ 
ment  of  existing  techniques  available  from 
vendors. 

3)  The  potential  solutions  must  then  be  assessed  to 
prove  their  industrial  viability  for  solving 
aerospace  problems.  The  assessment  work  will 
be  distributed  among  the  Partner  Companies,  not 
only  to  share  costs  but  also  to  involve 
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practitioners  inside  the  companies  and  ensure  the 
assessments  are  based  on  real  case  studies.  This 
will  ensure  that  results  can  be  used  immediately 
and  thus  gain  short  tenn  benefits. 

4)  The  solutions  which  have  been  recognised  as  en¬ 
hancing  working  practices  through  agreed  criteria 
will  be  kept  and  integrated  together.  The  AIMS 
generic  ECS  development  process  will  be 
modified  in  order  to  support  these  solutions  al¬ 
lowing  their  immediate  use  by  the  Partner  Com¬ 
panies,  thus  gaining  medium  term  benefits. 

5)  Finally,  based  on  an  agreed  AIMS  ECS  develop¬ 
ment  process  supporting  new  industrialised  sol¬ 
utions  to  actual  problems,  the  AIMS  team  will  be 
able  to  make  strong  recommendations  to  vendors 
concerning  the  environments,  the  tools  and  the 
methods  which  could  be  used  to  support  the  de¬ 
velopment  process,  thus  gaining  long  term 
benefits.  Tluough  this  cooperative  work  the 
AIMS  Project  will  be  in  a  strong  position  to  influ¬ 
ence  future  emerging  standards. 

To  carry  out  this  strategy,  the  AIMS  partners  have 
chosen  to  employ  the  majority  of  the  Team  within  the 
aerospace  industry  in  order  to  benefit  frtmi  a  detailed 
knowledge  of  aerospace  practices  without  being  tied 
into  the  production  deadlines  of  any  specific  product. 
However,  when  additional  help  is  required,  the 
AIMS  Team  draws  on  the  experience  of  many  other 
experts  from  national  research  laboratories  and 
system  or  software  houses. 

The  AIMS  Team  is  confident  that  the 
implementation  of  the  strategy  outlined  above  will 
result  in  helping  the  European  aerospace  industry  to 
work  together  with  more  efficiency  when  developing 
and  maintaining  ECSs,  thus  retaining  its  competitive 
advantage. 


The  Project  received  EUREKA  status  in  September 
1987.  Preliminary  discussions  were  conducted  be¬ 
tween  the  original  five  Partner  Companies’  to 
establish  the  long-term  objectives  and  the  overall 
Project  organization. 

During  the  DefiniHon  Phase  an  investigation  was  un¬ 
dertaken  to  determine  how  the  Partner  Companies 
carry  out  the  ECS  development  and  maintenance 
process  and  the  commtm  problems  experienced  by 
them.  The  potential  solutions  for  these  problems 
were  then  studied  theoretically  for  various  phases  of 
the  development  process  such  as  specification, 
design  and  testing. 
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Fig.  2:  AIMS  Project  Phasing 

During  the  Demonstration  Phase,  the  solutions 
identified  in  the  definition  phase  are  being  implem¬ 
ented  and,  using  real  case  studies,  their  industrial 
applicability  is  being  evaluated.  The  solutions  in 
isolation  are  not  sufficient,  therefore  research  into  the 
integration  of  the  solutions  is  being  undertaken. 

In  the  next  phase,  the  potential  integration 
technology  is  to  be  assessed  and,  using  real  case 
studies,  their  industrial  capability  shall  be  evaluated. 
A  migration  strategy  to  converge  aerospace  projects 
towards  the  AIMS  process  improvements  shall  be  in¬ 
itiated. 

AIMS  is  a  user-driven  project  with  its  roots  well 
inside  the  participating  companies.  To  maintain 
strong  links  with  the  companies,  members  of  the 
Team  work  within  their  own  organisations  and  there¬ 
fore  the  AIMS  Team  is  distributed  between  the 
countries  of  the  three  Partner  Companies.  Efficient 
communication  between  all  parts  of  the  team  is  vital, 
to  allow  a  wide  exchange  of  information,  and  this 
need  has  led  to  a  well  defined  but  flexible 
organisation  which  forms  the  backbone  of  the 
Project. 

A  clearly  defined  hierarchy  of  groups  co-ordinates, 
controls,  monitors  and  executes  the  Project  work. 
This  structure,  which  follows  the  EUREKA  project 
organisation  guide-lines,  facilitates  democratic  deci¬ 
sion  making  and  helps  to  ensure  that  each  partner 
company  actively  supports  all  the  Project  decisions. 


The  Demonstration  Phase  has  the  objective  of  pro¬ 
viding  evidence  of  the  benefits  that  may  be  gained  by 
implementing  the  solutions  proposed  in  the 
Definition  Phase,  in  onler  to  reduce  the  risks  of  de¬ 
veloping  or  acquiring  new  technologies.  For  this 
purpose  industrial  demonstrators  have  been  set  up  to 
evaluate  and  exploit,  where  possible,  techniques  and 
technologies  available  on  the  market  and,  in  some 
cases,  to  develop  new  techniques. 


1  CASA  (Spain)  and  MBB  (Germai^)  participated  in  the  Project 
from  19SS  to  1991. 
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5. 1  Industrial  Demonstraiion 

AIMS  has  developed  a  common  approach  for  the 
definition  and  assessment  of  the  demonstrators  to  en¬ 
sure  that  their  results  are  applicable  to  all  the  Partner 
Companies. 

This  approach  requires  that  both  the  problem  and 
solution  are  fully  understood.  This  understanding 
can  then  be  used  in  the  definition  of  criteria  to  assess 
the  solutions,  so  that  the  assessment  will  provide  ac¬ 
ceptable  proof  that  the  solutions  will  have  real 
benefits  over  current  techniques. 

To  understand  the  problems  in  the  ECS  development 
and  maintenance  process  it  was  necessary  to  consult 
aerospace  practitioners  who  have  hrst  hand 
experience  of  these  problems.  By  fully 
understanding  the  concepts  underlying  the  proposed 
solutions  it  is  possible  to  identify  the  impact  that 
these  solutions  would  have  on  the  efficiency  of  the 
ECS  development  and  maintenance  process. 

Having  identified  the  expected  impact  of  the 
solutions,  it  is  possible  to  define  the  scope  and 
criteria  for  assessment  of  the  solutions  in  order  to 
provide  acceptable  evidence  of  the  benefits. 

It  is  important  that  the  solutions  are  assessed  using 
real  project  information  in  order  to  show  the  viability 
of  the  solutions  in  the  real  world.  Proof  that  the 
solutions  provide  real  benefits  will  be  obtained  by 
comparing  the  results  of  assessments  of  the  new  sol¬ 
utions  with  those  obtained  from  using  current  tech¬ 
niques.  By  involving  the  aerospace  practitioners 
closely  at  all  levels  of  the  demonstrations  the  results 
will  be  immediately  available  to  them  for  use  in  im¬ 
proving  their  ECS  development  and  maintenance 
processes  on  current  projects,  even  before  an  overall 
result  for  AIMS  is  achieved. 

The  four  AIMS  demonstrators  ate  briefly  described 
below: 

1)  Collaborative  Working  in  Systems  Development  - 
This  demonstrator  is  being  undertaken  by  Euro¬ 
copter  France.  Its  objective  is  to  investigate  prob¬ 
lems  currently  encountered  when  developing 
systems  collaboratively,  especially  when  the  par¬ 
ticipating  partners  are  geographicaUy  distributed. 
This  demonstrator  is  assessing  various  collabora¬ 
tive  working  techniques  which  will  improve  the 
sharing  and  communication  of  project 
information,  and  the  required  organisational  sup¬ 
port  required  by  collaborative  projects.  The  as¬ 
sessment  of  this  demonstrator  will  be  performed 
based  on  a  sub-system  of  the  Tiger  helicopter. 

2)  Prototyping  and  Animation  of  ECS  Specifications 
-  This  demonstrator  is  being  undertaken  by  the 
Military  Aircraft  Division  of  British  Aerospace 
Defence  Ltd.  Its  primary  objeaive  is  to 
investigate  whether  tlK  use  of  prototyping  and 
animation  can  aid  in  the  validation  of  system  and 


software  specifications,  and  reduce  errors  intro¬ 
duced  during  the  requirements  and  specification 
phases.  The  dmonstrator  will  assess  an 
improved  notation  for  specifications  which  can 
also  be  animated.  The  assessment  will  be  based 
on  sub-systems  from  both  Hawk  and  EFA 
Projects. 

3)  Formal  Methods  for  Software  Design  -  This  dem¬ 
onstrator  is  being  undertaken  by  the  Avionics  and 
Systems  Direction  of  Aero^atiale's  Civil 
Aircraft  Division.  Its  objective  is  to  assess 
whether  the  use  of  formal  methods  in  the  design 
of  software  for  Embedded  Computing  Systems 
may  help  to  reduce  the  cost  and  time  required  for 
software  certification.  The  demonstrator  will 
assess  the  use  of  a  formal  notation  which  can  be 
formally  refined  to  Ada  code.  The  assessment 
will  be  based  on  a  sub-system  from  the  A340. 

4)  Support  for  ECS  software  test  activities  -  This 
demonstrator  is  being  undertaken  by  Alenia  De¬ 
fence  Aircraft  Division.  Its  primary  objective  is 
to  explore  innovative  tools  and  techniques  to  sup¬ 
port  software  testing  of  Embedded  Computer 
Systems  and  to  evaluate  their  impact  on  effort  and 
quality.  The  demonstrator  will  assess:  improved 
techniques  for  testing  and  the  state-of-the-art 
tools  used  to  support  these  techniques,  an  expert 
system  to  assist  with  the  management  of  the 
testing  activities,  and  the  feasibility  of  generating 
test  cases  from  formally  defined  specifications. 
The  assessment  of  this  demonsuator  will  be  based 
on  a  sub-system  from  EFA. 

Figure  3  shows  the  areas  of  the  life  cycle  as  covered 

by  the  demonsuators. 
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Fig.  3:  The  4  Demonstrators 
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The  invcdvement  of  the  practitioners  in  the  definition 
and  assessment  of  the  demonstrators  has  started  the 
process  of  introducing  the  new  techniques  and  tech¬ 
nologies  into  the  aerospace  oi^anisations,  which  is 
often  one  of  the  major  reasons  why  new  technologies 
are  not  adopted. 

5.2  Integration 

Through  the  demonstrator  projects  we  are  looking  at 
improvements  at  local  areas  within  the  life  cycle.  To 
make  use  of  all  these  improvements,  we  have  to 
identify  a  means  to  integrate  the  different 
technologies.  This  is  to  be  achieved  by  modelling 
the  activities  that  are  performed  within  the  develop¬ 
ment  process,  the  information  produced  and 
consumed,  aitd  the  controls  applied  to  the  activities 
and  the  infonnatioa  Collectively  these  models  form 
the  ECS  Development  Model  and  this  will  cover  es¬ 
sential  areas  related  to  technical  development, 
technical  managemern  and  organizational  manage¬ 
ment. 

By  using  the  models  we  can  identify  the  data  which 
is  required  and  produced  by  each  demonstrator. 
Based  on  this  information  we  can  determine  how  to 
interface  between  the  demonstrators  and  provide  a 
specification  for  their  integration.  The  models  can 
then  be  used  as  the  means  of  communication  between 
the  Partner  Companies  as  well  as  providing  a  more 
formal  definition  of  our  requirements  for  potential 
suppliers. 

The  models  have  been  developed  to  show  that  inte¬ 
gration  may  be  achieved.  This  concept  will  be 
proven  through  the  development  of  an  integration 
demonstrator. 

5.3  Exploiiatim 

The  aim  of  the  exploitation  work  is  to  define  how  the 
PartiKr  Companies  can  acquire  the  AIMS  solution  in 
a  timely  and  cost  effective  way.  This  work  will 
identify  how  environment  related  initiatives  external 
to  AIMS  may  be  utilised,  and  how  external  bodies 
may  be  influenced  to  move  towards  the  AIMS  phil¬ 
osophy. 

This  will  ensure  that  work  being  performed  outside  is 
not  duplicated,  but  that  it  could  be  modified  to  meet 
the  needs  or  long  term  requirements  of  the  aerospace 
community. 

5.4  Migration 

The  main  reason  for  the  existence  of  multi-aerospace 
collaborative  Research  &  Development  is  to  share  its 
risk  and  cost  and  then  to  share  the  benefit  of  its 
results  on  commercial  ventures  in  the  future.  As  s 
consequence  the  results  need  to  be  transferred  into 
use  for  the  benefits  to  be  gained. 


Achieving  this  transfer  requires  approval  of  the  R&D 
results  by  a  company  or  collaborative  project;  and  is 
not  necessarily  automatic.  For  example,  the  results 
of  the  ECS  development  process  improvements  will 
identify  how  much  such  improvements  will  save  and 
how  much  they  will  cost  (eg.  in  re-equipping  and 
training  development  stafO.  Decisions  on  their 
transfer  into  industrial  use  have  to  be  taken  at  a 
strategic  level  within  the  companies. 

One  solution  is  through  the  set-up  of  Migration 
Demonstrators  which  focus  on  the  problems  of  trans¬ 
ferring  proposed  process  improvements  onto  aero¬ 
space  development  projects  or  into  companies  (based 
on  process  improvement  demonstrators  previously 
carried  out  in  other  companies).  They  would  be  con¬ 
ducted  following  the  AIMS  approach.  The  objective 
would  be  to  re-use  the  problem  analysis  and 
proposed  solution  of  a  completed  demonstrator  as¬ 
sessment,  in  order  to  carry  out  a  low  cost  company  or 
project  specific  assessment.  This  would  result  in  the 
confirmation  or  revision  of  the  original  process  im¬ 
provement  results,  but  more  imponantly  would 
achieve  a  wider  acceptance  of  the  results. 

This  is  seen  as  a  means  of  bringing  about  technology 
transfer  at  the  collaborative  level  in  the  early  years  of 
the  use  of  these  process  improvement  techniques.  In 
its  own  right,  it  forms  a  low  cost,  low  risk  alternative 
to  (or  supportive  element  of)  the  proposed  migration 
programme. 

6  CONCLUSIONS 

This  paper  has  provided  an  overview  of  the  Project, 
and  the  pragmatic  approach  it  has  adopted,  in  order 
to  achieve  its  goals.  The  following  sub  sections 
identify  the  results  and  influences  the  AIMS  Project 
has  had  and  foresees. 

6. 1  Significant  Results  Achieved  to  Date 

To  date,  we  have  had  some  very  significant  achieve¬ 
ments.  Each  of  which  has  been  agreed  by  the 
aerospace  companies.  These  are: 

•  a  commcm  understanding  of  our  objectives,  ex¬ 
pressed  in  terms  of  refined  characteristics; 

•  a  common  understanding  of  the  ECS  development 
and  maintenance  process,  expressed  in  terms  of  a 
process  model  -  the  AIMS  ECS  Development 
Model; 

•  an  identification  of  the  major  aerospace  problems, 
expressed  in  terms  of  the  prxxress  and  its  impact  on 
our  objectives; 

•  an  aerospace  migration  strategy. 


However,  these  are  only  the  paper  documents  that 
describe  our  achievemenis,  but  do  not  describe  their 
impact,  which  is  what  really  counts.  We  have  seen  a 
change  in  attitude  within  die  companies,  and  a  reali- 
satitm  that  the  approach  we  have  (teflned  has  real 
benefits.  This  type  of  analysis  of  problems  is 
spreading  within  our  companies.  AIMS  has  been 
seen  as  a  model  project  for  the  level  of  cooperation  it 
has  achieved  between  the  partner  companies.  It  is 
seen  as  the  way  to  resolve  problems  with  potential 
future  partners  before  we  get  to  the  project  stage  of 
aircraft  and  ECS  development. 

Finally,  we  have  had  an  impact  on  other  international 
initiatives  such  as  the  Portable  Common  Interface 
Set  (PCIS)  Programme,  ensuring  they  take  into 
account  the  users'  view,  which  has  rented  in  the 
recognition,  now  widely  accepted,  that  the  user  have 
an  important  role  to  play  in  the  definition  of 
standards. 


into  the  aerospace  companies.  This  work  has  already 
influenced  our  work,  in  particular,  in  the  way  the 
demonstrator  assessments  are  being  performed. 

The  second  approach  of  using  practitioners  of  real 
aerospace  projects  is  slightly  more  subde.  An 
intimate  arid  pragmatic  communication  between 
practitioners  arid  techrwlogy  providers  has  been  es¬ 
tablished.  Solution  providers  are  forced  to 
uTKkrstand  the  problems  and  working  environment 
of  the  practitioners,  rather  than  the  practitioners 
having  to  understand  the  technologies  and  work  out 
for  themselves  how  it  solves  their  problems.  Finally 
the  practitioners  have  been  able  to  use  the  demon¬ 
strators  and  therefore  have  the  confideiKe  that  the 
problems  have  been  solved  and  that  the  solution  is 
operationally  applicable.  This  has  resulted  in  the 
practitioners  going  back  to  their  departments  and 
selling  the  technologies  to  their  colleagues  and  man¬ 
agers. 


6.2  Influence  on  Industrial  Practice 

AIMS  has  the  advantage  that  it  has  access  to  a  great 
wealth  of  industrial  experience  and  industry  practi¬ 
tioners.  Therefore,  it  has  uckled  the  problem  of 
transferring  improved  working  practices  and  support 
technology  into  industrial  use  in  two  complementary 
ways.  The  first  approach  was  to  understand  what 
problems  would  prevent  us  from  introducing  any  im¬ 
proved  working  practices  and  support  technologies 
into  the  parmer  companies.  The  second  was  to  use 
practitioners  of  real  aerospace  projects  on  the  Dem¬ 
onstration  Assessment  projects. 

The  problems  preventing  technology  transfer  are  of  a 
political,  financial  and  technical  nature:  all  these 
have  to  be  tackled  if  the  Project  is  to  be  successful. 
The  identification  of  these  problems  has  resulted  in 
the  defmition  of  a  migration  strategy,  which 
identifies  a  pragmatic  approach  to  introducing  im¬ 
proved  worldng  practices  and  support  technologies 


6.:i  Significant  Result.s  Fnre.seen 

In  the  short  term  we  will  receive  the  results  from  the 
demonstrator  assessments  which  will  identify  how 
far  we  have  gone  towards  achieving  our  goal  of  suc¬ 
cessfully  introducing  improvements  in  working 
practices  and  support  technologies  into  the  Partner 
Companies.  Tte  integration  work  will  identify  how 
improved  working  practices  and  support 
technologies  can  be  integrated  together.  Relevant 
standards  will  be  assessed  to  see  if  they  are 
applicable  in  our  domain. 

This  will  enable  us  to  identify  the  capabilities 
required  for  future  aerospace  projects  using  AIMS 
techniques  before  they  are  initiated,  therefore  leaving 
them  to  concentrate  on  getting  the  project  work  done. 

In  this  way  we  believe  we  will  be  able  to  demonstrate 
the  achievement  of  our  objectives  of:  improved  pro¬ 
ductivity,  stabilized  time  schedules  and  effective 
cooperation. 


Discussion 


Questioa  K.  BRAMMER 

You  have  mentioimed  that  you  proved  the  improvanent,  gained  by  applykg  the  AIMS  soluiioos.  to  decision-makeis  at 
decision  level.  This  is  a  very  important  issue.  Can  you  expbm  how  you  do  this  in  practice? 

Reply 

Basicallyby  giving  the  measures  of  the  improvements.  We  use  metrics  from  other  projects,  if  they  are  available, 
otherwise  we  nm  case  studies  where  measures  ate  taken  usmg  previous  techniques  and  later  using  the  enhanced 
techniques.  It  is  important  to  keep  other  oooditians  the  same,  litis,  axipkd  with  the  support  of  the  practitioners,  is  to  our 
experience  the  best  way  to  convince  a  dedskn-maker. 

Question  C.  BENJAMIN 

What  limitaition  did  you  tun  into  when  using  Siatemate? 

Reply 

People  have  some  trouble  initially  with  its  notation,  but  this  is  quickly  overcome. 

A  limitation  has  been  encountered  for  the  specification  of  real-time  systems  which  have  an  intensive  use  of  data. 
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1.  SUMMARY 

An  object-bcMd  environment  for  inqilanenting  (fistiib- 
uted  tyetenn  u  deiciibed.  Thu  can  be  med  to  create 
woridi  of  interacting  objects,  operating  over  a  network 
ofprooeaaon.  The  preciae  manner  of  the  diatributian  ia 
ttan^awnt  to  the  ol^ectt  within  the  enviionmapt 

A  prototype  of  thie  environment  ia  being  implemented  in 
Ada,  augmented  by  aupport  for  object-oriented 
comtnicta  lliia  ia  intended  for  uae  in  real-tune  aimula- 
tiona  of  combat  miaaiona  and  will  be  known  aa 
Multi-aim. 

2.  INTRODCJCram 

Thia  paper  deacribea  aome  of  the  conaiderationa  behind 
the  deaign  of  an  object-baaed  environment  huended  to 
aupport  the  implemedtatian  of  certain  typea  of  diatribut- 
ed  real-time  ayatenL  The  ayatema  of  iniereat  for  thia 
work  are  typified  by  hawing  a  aignificant  amount  of  glo¬ 
bal  interaction  among  the  varioua  aoftware  entitiea 
repreaented  within  the  environment,  that  ia,  onea  in 
which  it  it  not  poaaible  e  priori  to  define  locahaed  limita 
for  the  inteiactiona  of  any  entity. 

Thia  characteriatic  ia  ftequently  met  in  oomtut  miaaicn 
aiinulalort,  in  abich  a  number  of  entitieB,  or  playen,  in¬ 
teract  in  variout  wpya  during  the  couiae  of  a  armulated 
miatian.  ftianotpoaaiUetotay  in  advance  which  play- 
era  will  interact,  or  over  abat  range  the  imeraction  will 
occur,  and  ao  all  informatian  governing  aucfa  mteractiona 
oeeda  to  be  globally  available.  Certain  of  tfaeae  entitiea 
are  controlled  by  human  pilola,  leading  to  a  reipjiiement 
for  real-time  operation,  typically  on  a  group  of  graphica 
workatatkmt,  Imkad  by  a  medium-bandwidlh  local  area 
netwofit*. 

In  atteoqiling  to  deaign  a  toftwate  ertvitooment  within 
wfaicfa  auch  diatiibuted  aimulatiQnt  can  be  conducted,  the 
approach  we  have  taken  it  to  enn^oy  aoftware  objecta  to 
r^ieaent  entities,  groupetrfentitietutd  component  partt 
of  entitiea. 

The  use  of  object-orientation  in  itt  full  aenae  promisea  to 
result  in  ayston  deaignt  vdiich  are  eatier  to  maintain  and 
enhance  tta  previoua  approaches  to  aoftware  atiucture. 
The  foia  main  conoqils  uauaily  regarded  at  duracteria- 
ing  an  object-oriented  aystem  ate: 

a)  Encapsulation -a  software  object  iaconqjlelelytetf- 
cotmiinBd,  having  aft  dw  code  and  dam  altribines  it 
needt  hidta  wUan  it,  and  accessible  only  dirough  a 


well-defined  set  of  operation  calls. 

b)  Dam  Abstraction  -  the  use  of  an  objea  specification 
ai  a  template  to  enable  the  creation  of  multiple  in- 
atances  thsing  the  tame  operations,  but  each  with 
independent  dam  attributes. 

c)  taheiitance- the  ability  to  define  a  fresh  object  data 
having  fti  the  operations  and  attributes  of  an  existing 
dais,  witii  additional  attributes  and  operations  of  its 
own. 

d)  Dynamic  Binding  -  the  ahility  to  specify  an  object 
operation  to  be  performed,  without  needing  to  spec¬ 
if  until  run-time  the  class  of  object  which  will 
perform  it 

It  is  important  to  emphetiae  that  the  uae  of  object- 
oriented  methods  is  not  dependetu  on  any  particular  pro- 
g ramming  language  or  environment  Rather  it  ia  an 
approach  to  organising  and  planning  computer  pro- 
grama,  m  approach  which  can  be  applied  to  •  greater  or 
lesser  extent  in  all  software  devdopment.  However,  ded- 
icaled  object-oriented  programming  ayatema  auch  aa 
Smalltalk  80^.  provide  comprehensive  auppoit  for  the 
appnmcfa,  and  00  extensions  to  existing  languages  such 
ai  Objective  or  C-h-*  have  also  been  developed  The 
extettt  to  wluch  00  concepts  can  be  realised  in  a  Fbitm 
eavironment  has  also  been  exploied^l  In  addition,  the 
features  and  dam  structures  of  Ada  provide  a  good  match 
to  the  tequiiemenla  of  OOD*.  Within  the  niA,  work  has 
concentialed  on  die  provision  of  run-time  aupport  librar¬ 
ies  for  constructing  wealds  of  interacting  objects  in  Ada’. 

The  Ada  language  was  chosen  for  the  main  part  of  the 
environinem  because  of  its  high  degree  of  standardisa- 
tion,  pormbility  and  good  aoftware  engineenng  features. 
It  is  not  however,  fully  object-oiiented  as  it  currently 
lacks  fadlitiea  for  inhentance  and  dynamic  binding.  The 
enviromnent  makes  use  of  Ada’s  encapsulation  and  dam 
ftntiactioo  capabilities  to  enable  the  definition  of  self- 
contained  clam  cf  objects  with  well-defined  interfaces. 
An  ernulmicD  of  Dynamic  Binding  is  provided  as  a  key 
paitoftheenvironmenL  Thia  allows  the  core  parts  of  die 
environment  to  have  control  over  the  operation  of  the 
objecti  wftfain  ft,  even  though  these  objects  may  not  exist 
when  die  environment  is  compiled. 

In  designing  this  environment,  we  have  chosen  to  omit 
any  direct  use  of  inheritance,  pertly  because  it  is  difficult 
to  imtftemetft  in  Ada,  and  also  because  we  have  found 
that  defining  conqionent  objects  is  a  more  flexiUe  way 
of  constructing  complex  objects  fex  simulation  purposes. 
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For  tbi*  reann.  the  tenn  “Otqect-BaMd"  hai  been  uied 
to  deKiibe  the  environment,  in  prefieience  to  "Object-O 
noMd".  Ihe  design  of  comiioneitt  parts  which  can  be 
readily  re-used  in  different  conlexu  is  an  importaru 
method  for  reducing  the  effort  required  to  produce  com¬ 
plex  simulahom. 

One  importatt  constraint  on  this  wmk  was  the  requiie- 
ment  to  be  able  to  make  use  of  a  large  set  or  existing 
models,  mainly  written  in  Fortran.  This  baa  been 
achieved  by  the  provision  for  the  use  of  customised  Ada 
harnesses  through  which  individual  models  can  be 
coinrolled  The  modds  themselves  can  then  be  written 
in  any  language,  and  are  readily  portdrie  to  other  simu- 
lahon  envirotunents‘° 

3.  THE  DISTRIBUTED  (» JECT  DATA-BASE 

Ihe  core  pert  of  this  environment  is  a  data-base  contain¬ 
ing  basic  informaticn  about  all  the  objects  in  existence 
within  the  environment  The  information  stored  includes 
the  object's  name,  references  to  iu  owner  and  to  its  class 
and  a  list  of  component  objects  of  which  it  is  comprised. 
Bwh  object  fits  into  a  hierarchy  of  componeru  paru, 
starting  with  a  single  Top  object 

The  information  in  this  data-base  is  replicated  within 
each  processor,  so  that  each  has  a  complete  set  of  entries 
for  all  the  objects  in  the  other  processon,  as  well  at  its 
own  local  objects.  This  replication  cnsutes  diat  access  to 
the  information  in  the  dam-base  it  fast,  requiring  no 
communication  with  other  processoa.  When  an  object 
is  created  dynamically ,  an  entry  for  it  is  made  in  the  local 
processor’s  dma-base,  and  a  single  message  is  broadcast 
to  the  other  processors  containing  the  information  they 
need  to  create  the  corresponding  entries  within  their  own 
data-bases. 

Objects  can  be  destroyed  dynamically,  as  well  as  created 
Again,  a  single  message  suffices  to  iqxlate  all  the  data¬ 
bases.  The  storage  allocated  to  the  object  is  retained 
within  its  class,  to  that  it  can  be  reused  when  another 
object  is  created  This  eliminates  problems  caused  by 
attempting  to  use  the  garbage  collation  facilities  pro¬ 
vided  by  vaious  compilers. 

The  prssdple  that  each  basic  operation  on  the  data-base 
results  in  only  a  single  message  between  processon  it 
very  important  for  real-time  operation  of  a  multi¬ 
processor  system.  The  alternative,  in  which  an  operation 
would  involve  a  request  message,  followed  by  a  re- 
qxmse  message,  would  result  in  cmnplicaticos  within 
tte  requesting  processor,  which  would  either  have  to 
wait  for  the  response,  or  remember  to  expect  it  on  a  sub¬ 
sequent  cycle.  The  single  message  principle  has  been 
followed  throughout  this  work,  including  the  genetic 
communicaiion  ficilities  described  in  die  next  sectian, 
and  the  simulation  applicatiOD  described  in  section  3. 

When  apfdied  to  object  creation,  the  tingle  message  prin¬ 
ciple  means  that  a  creation  request  made  in  one  proces¬ 
sor  can  return  a  reference  to  the  new  object  imm^ately 
for  use  within  the  creating  program,  even  diough  the  new 
object  may  be  an  instance  cf  aclats  implemented  on  an- 


.  other  processor. 

As  well  as  n^ipotting  objects  which  are  uistances  of  a 
data,  the  data-base  also  has  support  for  "single  objects", 
which  are  not  associated  with  any  particular  elms  A 
tingle  object  u  used  to  refer  to  a  coo^ete  package  of 
software  which  hat  not  been  written  in  the  object- 
oriented  style,  and  only  contains  a  single  set  of  attributes. 
This  is  particularly  important  when  le-using  strftware 
from  ot^  projects  which  hat  not  been  written  using 
data  abstraction.  Creation  and  destmehon  of  single  ob¬ 
jects  it  handled  rather  differently  from  creation  and 
destructioo  of  instances,  since  there  is  no  class  object  to 
refer  to. 

The  final  fedlity  offered  by  the  object  data-base  is  sup¬ 
port  for  an  emulation  of  dynamic  binding.  Ada  does  not 
currently  pomit  dynamic  binding,  which  involves  selec¬ 
tive  cal^  of  object  operations,  dqiendem  on  the  type 
object  encountered  at  nm-hme.  However  it  is  vital  to 
have  this  ability,  since  it  permits  the  construction  of  gen¬ 
eral  purpose  facility  packages  which  can  make  use  of 
objea  operahons  without  knowing  at  conqiile-time  what 
classes  of  objects  will  be  available  to  them.  The  simula¬ 
tion  framework  described  in  section  3  makes  use  of  this 
principle  to  contrd  the  tiine  integration  of  models,  and  to 
pass  messages  to  them  from  other  models. 

4.  GENERIC  COMMUNICATIONS 

The  objects  within  this  environment  clearly  need  to  com- 
rmmicaie  information  governing  the  interactions  between 
them.  The  environment  has  facilities  to  allow  this  com¬ 
munication  to  occur  over  a  distributed  world  of  objects, 
based  on  the  following  principles: 

a)  The  nature  of  the  informatian  to  be  communicated 
ia  determined  by  the  designer  of  the  objects,  not  by 
the  object  environraem.  This  ensures  t^  the  envi- 
ronmoit  is  truly  general-purpose.  This  lack  of 
specitdisation  is  achieved  by  providing  the  commu¬ 
nication  facilities  in  the  form  of  generic  Ada  pack¬ 
ages,  whidi  are  instanhaled  by  the  object  designer 
to  implenaent  the  specific  communication  requite- 
menta  of  the  set  of  objects  under  consideration. 

b)  The  communications  are  independent  of  die  class 
of  object  being  communicated  with.  It  is  frequently 
the  case  that  identical  information  will  be  generated 
by  (w  required  by)  objects  belonging  to  diflerem 
classes.  No  distinction  is  drawn  between  these 
communications;  in  other  words,  it  it  not  necessary 
to  know  what  type  of  object  is  being  conummicated 
widi  either  at  compile  time,  or  at  run-time.  This 
principfe  makes  it  possible  to  introduce  new  classes 
of  ol^t  without  redesigning,  or  even  re-compiling, 
the  existing  classes,  jirovided  that  the  nature  of  the 
communication  does  not  change. 

c)  The  conuminications  are  also  indepmident  of  the 
distribution  of  objects  between  the  various  proces- 
son  in  use  for  a  particular  job.  The  various  routing 
opmations  required  ate  handled  transparently  by  the 
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amromnent  m  m  the  objects  an  concemed. 
Hih  is  vital  if  objects  an  to  be  nsHisabie  m  diftaeat 
contests.  The  sane  object  code  can  be  used  for  a 
aon-nal-tiiiie  singie  processor  work  as  for  a  leal- 
tune  lailti-pracessor  simulatioa 

d)  The  commiBiication  packages  can  be  added  to  in  » 
incninental  rnamer.  Thia  makes  it  possible  to  de¬ 
fine  fundamental  communication  anvices  used  by  a 
wide  variety  of  objects,  while  more  specialised 
commimications,  uied  by  a  limited  set  of  objects, 
can  be  added  later,  withou  affecting  any  (rf  the  oth¬ 
er  objects.  Again,  this  encourages  the  te-uae  of 
existing  object  definitions. 

The  environment  cunenly  supports  two  diatinct  types  of 
communication,  one  in  which  an  object  can  lequeat  in¬ 
formation  about  the  state  erf  another  object,  and  a  second 
in  which  one  object  can  send  a  message  to  another.  Both 
of  these  adhere  to  the  principle,  described  sbove,  that 
each  basic  operation  within  the  environment  be  complet¬ 
ed  by  a  single  ineer-proceuor  communicatioa 

4J  DataStoraa 

Data  Stores  provide  the  means  by  which  one  object  can 
request  information  about  the  stale  of  another.  Theypro- 
vkie  for  the  global  information  transfer  referred  to  at  the 
start  of  Section  1.  Data  Stores  behave  tike  extensions  to 
the  object  data-base;  they  have  a  slot  for  each  object 
which  can  hold  informabon  dbout  certain  aspects  of  the 
state  of  that  object  and  are  repticaied  in  each  processor. 
When  information  is  placed  in  the  data  store  in  one  proc¬ 
essor,  it  is  automatically  broadcast  to  all  the  others,  and 
thus  becomes  global  data  available  for  inspeebon  by  any 
ot^t  in  the  system. 

One  useful  feature  trf  the  data  stores  is  that  each  one  has 
an  index  to  all  die  objects  which  have  placed  dau  in  it. 
This  cm  be  used  by  an  object  retrieving  the  dau  to  scan 
through  all  the  data  which  is  currently  available  within 
the  environment,  and  tluis  explore  the  world  of  objects  in 
which  it  finds  itself. 

This  facility  makes  it  possible  to  design  objects  whidi 
cm  uneract  with  many  other  objects,  without  needing  to 
be  explicitly  given  the  idenbbes  cf  those  other  objects. 
This  greatly  enhances  the  flexibility  of  use  of  objecu 
within  the  mvironment  snd  the  ease  with  which  the  ob¬ 
ject  populabon  cm  be  modified 

Dau  stoes  also  coittain  informabon  about  the  bme  la- 
tesKy  or  staleness  of  the  daU  within  them.  This  will 
allow  inqilemmtation  of  extrapolabon  algorithms  to 
minimiaeerron  due  to  latency.  These  algorithms  ate  not 
m  inherent  part  of  the  environment,  since  the  choioe  of 
whether  or  not  to  uae  them  is  one  of  the  design  trade-offs 
best  left  to  the  object  constructor. 

42  Evert  llandlfrs 

In  contrast  to  the  dau  stores,  in  which  the  communica- 
bon  is  inibated  by  the  receiver  of  the  informabon,  m 
event  handler  allows  the  soiree  of  the  irdbiinabon  to  in- 


ibate  a  commumcaboa  To  do  this,  the  source  object 
schedules  m  event  for  the  receiving  object.  This  event, 
and  my  associated  dau  lelevatu  to  it,  is  placed  on  m 
event  queue  in  the  event  handler  package.  Whm  bus 
event  comm  to  the  head  (d  the  queue,  the  handler  tends 
it  on  to  the  receiving  objeo  by  foiciiig  it  to  execute  one 
of  its  operations. 

Eveatt  handlen  are  instmbated  by  the  object  designer  to 
handle  teu  of  lelaud  events,  e^  of  which  cm  have 
different  daU  associated  with  it  They  provide  the  meant 
of  constructing  disciele-evcnt  timulsbon  models,  at  de- 
Kbbed  in  die  next  seebotL  Event  handleit  make  use  of 
the  dynamic  binding  emulabon  facility  to  force  objeett 
to  reqxmd  to  their  evantt.  This  ensures  that  the  event 
handlen  cm  be  defined  independmtiy  of  the  objects 
which  will  commimtcau  throu^  them. 

5.  APPLICATION  TO  SOMIILATION 

The  main  applicabon  cutiendy  envisaged  for  this  mulb- 
processor  environment  it  to  real-bme  combat  mission 
timulaton.  These  comprise  a  number  of  "piloied  work- 
atabona"  -  powerful  graphics  workstabons  equipped  with 
a  aub-aet  of  aircraft  controls  -  at  which  a  pilot  cm  com¬ 
mand  the  operabon  of  a  tingle  combat  aircraft  model 
within  the  simulation.  A  cotrylete  simulator  comprises 
amimber  of  such  worksttriens,  within  which  the  aircraft 
models  cm  interact  with  each  other  and  with  a  variety  of 
other  models,  such  at  missiles  and  ground  forces. 
bat  mission  timulaton  are  used  in  MIA  to  invesbgate 
various  aspects  the  duign  of  mission  support  and  weap¬ 
on  syatemt  for  aircraft  under  realistic  conditions  of 
tinhdated  combat. 

The  environment  described  in  the  preceding  seebons  will 
be  used  to  im|;dement  a  aimulabon  support  framework, 
Mulb-tim,  capable  of  running  a  simulator  coDopriting 
mulbple  claasea  of  models.  Use  of  the  generic  commu- 
nicruions  mechanisms  will  allow  the  interactions  be- 
twem  diese  models  to  be  qiecified  in  ways  which  do  not 
depend  on  the  mix  of  other  raodelt  in  the  aimulabon,  or 
on  the  way  in  which  they  are  distributed  between 
processors.  Figure  1  shows  the  overall  software  ttne- 
ture  for  the  Mtib-tim  framework.  Models  cm  be  writtm 
in  a  variety  of  computer  languages,  as  long  as  each  is 
provided  widt  m  Ada  harness  through  which  the  envi¬ 
ronment  cm  cotdrol  the  model.  This  feature  IS  intended 
to  encourage  re-use  of  exisbng  models  writtm  in  C,  PoT- 
trm  or  Parcal  as  well  as  development  of  new  models 
writtm  in  spedalised  declarative  languages  like  Prolog 
andPril". 

Both  cotkinuoua-bme  and  disciete-evem  models  will  be 
accommodated  Indeed,  the  same  model  cm  have  both 
continuous  and  discrete  aspecb  to  itt  behaviour.  The 
operabm  of  die  cotibmious  models  will  be  interleaved 
automabcally  with  my  discrete  evenu  to  as  to  m«rt«in 
diem  in  bme  tynchronisaboa  The  control  of  both  con- 
bnuous  models  and  discrete-eventa  is  to  be  performed  by 
a  scheduler,  local  to  each  processor.  This  will  have  bodi 
real-bme  and  non-ieal-time  modea  of  operabon  and  will 
control  the  models  in  itt  proceaaor  by  making  uae  of  the 
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dyuouc  binding  emulttion  provided  by  the  object 

dUn-beie. 

In  Older  to  do  due,  it  will  be  neceisary  to  geaumt  Ada 
package  bodies  to  call  opentiam  wle^vely  from  mod- 
els  at  naHime.  dependent  on  the  type  of  model  in  use. 
These  are  lefened  to  ai  "dynamic  binding  packages", 
and  can  be  produced  automatically  by  a  code  goieretor 
prognoL  Aa  they  are  the  final  piecai  of  software  to  be 
compiled,  it  will  be  particularly  straightforward  to  intro¬ 
duce  a  new  type  of  model  into  the  simulanoa  Ailthstis 
needed  will  be  to  moifify  the  instnictioas  to  the  code 
gtmtftrmtnr  to  include  s  lefeRDce  to  the  spedficstion  of 
the  new  model,  nm  the  generator  to  regenerate  the  dy¬ 
namic  binding  packages,  and  re-make  the  executable 
prognm.  No  oto  models  or  parts  of  the  envirorunent 
need  be  recompiled  (Figure  2). 

The  communication  packages  required  for  the  simula¬ 
tion  are  introduced  by  similar  means.  A  group  of  models 
"Miring  use  of  a  common  set  of  communicationi  pack¬ 
ages  can  be  formed  up  into  a  modr/ orvAhw,  from  which 
the  models  required  for  a  specific  simulation  can  be 
readily  selected.  These  mo^Us  should  work  together 
without  needing  any  further  modificatian.  The  develop¬ 
ment  archives  of  models  for  different  purposes  md 
levels  of  fidelity  should  greatly  reduce  the  effort  required 
to  set  up  specific  simulatiaos. 

The  prototype  simulstion  framework  will  be  controlled 
inid^y  by  a  temporary  keyboard  interface  for  interpret¬ 
ing  the  commands  needed  to  create  instances  of  models. 
clotK  them  from  existing  instances  (together  with  all 
their  conqxnent  ports),  schedule  evctus  for  them  and  tun 
the  simuhuioa  All  (rf  these  commands  will  obey  tbe 
single  message  principle  outlined  above.  This  interface 
is  to  be  constructed  so  that  it  can  readily  be  replaced  with 
mote  advanced  Graphical  User  Ineerfaoes  when  needed - 
nertfaer  tbe  object  environment  nor  the  models  need  de¬ 
pend  on  it  (Figure  2). 

«.  C(mCX4JS10NS  AND  FURTHER  WORK 

In  this  paper  we  have  described  an  object-based  envi¬ 
ronment  intended  for  use  on  a  multi-processing  network 
having  relatively  low-bandwidth  communicaticsK.  Its 
main  characteristics  are; 

a)  It  provides  for  a  hierarchical  decompositian  of  ob¬ 
jects  into  cooqxnem  parts,  with  the  conqxxieitt  objects 
split  between  processors  in  an  arbitrary  manner. 

b)  It  is  written  entirely  in  Ada,  with  provision  for  multi¬ 
language  working  wit^  an  object,  to  encourage  re-use 
of  existing  code. 

c)  It  provides  generic  ccamnunications  between  ob¬ 
jects,  both  for  objects  to  send  intonution  to  others,  and 
for  objectt  to  request  information  about  others. 

The  main  area  of  use  envisaged  for  this  environment  is  in 
the  fidd  of  simulation,  i^iere  a  simulation  framework, 
Milti-sim,  supporting  a  mixture  of  pseudo-contiinious 
and  discrete-event  modelling  it  being  constructed.  The 


initial  urget  applicsskn  is  to  the  real-time  combat  mis¬ 
sion  timulatioDt  for  both  rotary-wing  and  fixed-wing 
tucraft.  uodestaken  by  DRA  Famborough.  The  archive 
of  compatible  models  which  will  be  built  up  for  this  pur¬ 
pose  should  also  find  use  in  hardware-in-the-loop  testing 
(rf  fligbtworthy  equipmeiu  and  also  m  operational  effec- 
tiveneas  studies  in  related  areas. 
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1.0  SUMMARY 

Advanced  lyetem  architecturee  bring  unprecedented 
capabilitice  to  integrated  avionict  syttemt.  To  take 
advantage  of  the  procceiore,  eyttem  topologice,  and 
algorithma,  software  architectures  need  to  be  open  and 
flexible  both  to  integrate  new  featuiet  into  existing 
designs  and  to  map  applications  onto  new  processing 
architectures.  To  date,  development  tools  have  focused 
on  the  means  to  make  general  improvements  in  produc¬ 
tivity.  Many  good  approaches  in  software  reuse  (e.g., 
CAMP),  modeling  and  simulation  (e.g.,  Matrix-X, 
Matlab)  and  CASE  tools  (e.g.,  RDD-100,  Teamwork) 
concentrate  on  improving  portions  of  the  life  cycle.  The 
authors  believe  that,  for  avionics,  it  is  necessary  to 
extend  and  integrate  these  technologies:  to  move  reuse 
into  requirements  and  analysis,  to  smooth  the  tranridon 
from  system  and  algorithm  design  and  validation  into 
real-time  applications,  and  to  use  CASE  tools'  document 
generation  and  consistency  management  to  flow  design 
decisions  into  impltmentadotu. 

This  paper  describes  the  Domain-Specific  Software 
Architectures  Avionics  Development  Application  Gener¬ 
ation  Environment  (DSSA-ADAGE)  un^  development 
for  the  United  Stales'  Defense  Advanced  ReMarch 
Projects  Agency  (DARPA)  and  the  USAF’s  Wright 
Laboratory.  It  introduces  the  goals  of  the  project, 
recent  results  in  the  development  of  a  reusable  software 
architecture  for  integrated  avionics,  a  description  of  the 
process  used  to  develop  the  architecture  and  an  over¬ 
view  of  the  ADAGE  develo(»nent  environment  The 
remainder  of  the  paper  is  devoted  to  presenting  the 
formal  languages  that  describe  the  problem,  solution 
and  implementation  views  of  the  avionics  architecture. 

2.0  BACKGROUND 

DARPA's  Domain-Specific  Software  Ardiitectures 
(DSSA)  project  is  working  to  create  an  innovalive 
approach  for  generating  control  systems.  The  goal  is  to 
use  formal  descriptions  of  softirare  architectures,  and 
advances  in  non-linear  control  and  hierarchical  control 
theory,  to  generate  avionics,  command  and  control,  and 
vehicle  management  applications  with  an  order  of  mag¬ 
nitude  improvement  in  productirity  and  quality. 
Together  with  researchers  from  Massachusetts  Imtitute 
of  Technology,  Univwsity  of  California  at  Irrine,  Uni¬ 
versity  of  Texas  at  Austin,  and  University  of  Oxford, 
IBM  is  developing  an  integrated  environment  for  sped- 
lying,  evahuting,  and  generating  real-time  integrated 


avionics  applications.  Focusing  on  Navigation,  Guid¬ 
ance,  and  Flight  Director,  the  project  is  defining  an 
Avionics  Knowledge  Representation  Language  that 
specifics  the  features  and  constraints  of  avionics  software 
architectures.  The  language  will  permit  the  non¬ 
procedural  specification  of  applications  and  drive  graph¬ 
ical  representations  of  data  and  control.  This  approach 
relies  on  the  ability  to  separate  the  architecture's 
problem-oriented  features  from  its  sohition-oricnted 
implementation  constraints.  It  will  allow  a  systems  engi¬ 
neer  to  spediy  the  system  in  domain-specific  terms 
(filters,  processors,  sensors,  rates)  and  let  software  com¬ 
position  and  constraint-based  reasoning  tools  provide 
the  implementation  details  of  scheduling  and  data 
access. 

3.0  DOMAIN  ANALYSIS  PRELIMINARY  RESULTS 
An  avionics  system  integrates  the  complex  components 
of  crew,  airframe,  posrer  plants,  sensors,  and  specialized 
subsytems  into  an  int^gent  airborne  system  for 
achiering  specific  mission  objectives  within  time  and 
space  constraints.  These  specialized  subsytems  and  thdr 
supporting  arionics  system  capabilities  require  access  to 
common  time  crifical  data  produced  throughout  the  air¬ 
borne  system  sritfa  minimum,  quantified  delays  to 
support  cmnplex  subsystem  dynamic  stabilization,  valid 
solution  gcsieration  and  valid  ftision  of  varied  data  for 
eventual  interpretation  by  crew  members.  Impediments 
to  the  availal^ty  of  the  time  crifical  data  are  related  to 
both  the  system  architectural  and  system  development 
requirements. 

As  new  avionics  architectures  expand  to  include  new 
complex  subsystems,  the  processing  required  to  meet 
hard  real-time  deadlines  increases.  New  architectures 
are  also  responsible  for  creating  wide  variances  in 
avionict  computer  hardware  topology  and  associated 
data  transfer  requirements  putting  pressure  on  existing 
scheduling  paraifigms  and  communication  mechanisms. 
In  the  current  acquisition  environment,  and  certainly  in 
the  future,  physical  diaracterizafions  of  many  system 
conqsonents  arc  not  availaUe  during  the  ewiy  stages  of 
a  dcvelopmeoL  Since  tdl  implementations  of  avionict 
systems  are  approximations  of  physical  syttemt,  devel¬ 
opers  are  forced  into  an  iterative  devdopment  and 
refinement  proceu  of  models  and  analyses  which  are 
often  accomplished  without  automated  tools  to  support 
the  enfire  life-cycle. 


Presented  at  an  AGARD  Meeting  on  Aerospace  Software  Enpneering  for  Advanced  Systems  Architectures',  May  1993. 


OSSA-AOAQE  :  iMonlei  Domain  AppUcatlen  Qantratlofl  EmAonmam 


Flfura  1.  OSSA-AOAOI  Ciwtrenmanl.  ExacutaMa  pracaaM*  and  advancad  dawalopmaM  toolt  halo  daaignari  craata  avionict  lyalamt  ty  auto- 
madng  a  aplral  ArcMtactuna-baaad  OaMMopmam  PraeaaaCt]. 


3.1  OSSA-AOAGE 

The  OSSA-ADACE  approach  ti  baaed  on  the  premiae 
that  many  of  the  probiema  in  Navigation,  Guidance,  and 
Flight  Director  are  well  underatood.  For  any  new 
ayatem,  aeveral  featurea  win  require  new  and  innovative 
techniquea  but  many  componenta  and  aubayatema  can  be 
built  by  combining  and  adapting  eaiating  solutiona. 
Therefore,  domain  anaUyna  can  be  uaed  to  identify  com¬ 
ponenta  and  conatrainia  inherent  in  the  avionka  domain. 
Concepta  in  the  domain  can  be  organized  both  from  the 
perspective  of  the  physical  problems  that  they  solve  and 
from  the  way  the  componenta  work  together  in  a  com¬ 
puter  program  to  solve  them.  Thia  organization  of  com¬ 
ponenta,  connecdona,  interfaces  and  behaviors  is 
referred  to  as  a  Domain-Specific  Software  Ardutecture 
(DSSA).  A  DSSA  not  only  provides  a  framework  for 
reusable  software  componenta,  but  it  also  organizes 
design  rationale  and  atructurea  adaptability. 


for  embedded  ayatema  by  combining  componenta 
and  configuration  data/parametcn  with  implemen¬ 
tation  models,  and 

•  a  formal  representation  of  iterative  development 
process  models  and  process  measurement  tools  to 
guide  user  actions. 

3J  Dtmtam  Aaafyaia  Proetst 

One  of  the  primary  goads  of  the  DSSA-ADAGE  project 
is  to  use  domain  analysis  to  engineer  an  architecture  and 
auodated  componenta  that  can  later  be  uaed  to  rapidly 
devdop  avionics  requirements  and  software.  Thia 
domain  amalyaia  is  following  a  process  that  defines  a 
medianiam  for  the  orderly  exploration  of  the  problems 
and  solutiona  in  an  application  domain[2].  The 
process,  shown  in  Figure  2  is  baaed  on  several  previ¬ 
ously  aucceaaftil  approaches  to  domain  analysis[3,  4]. 


As  part  of  DARPA’s  program  the  DSSA-ADAGE  team 
is  building  an  ardutecture  and  a  hypermedia-based  envi¬ 
ronment  that  assists  analysts  aiul  software  devdopers  in 
automating  avionics  devdopmenL  The  ADAGE  envi¬ 
ronment  depicted  in  Figure  1  relies  on: 

•  constraint  based  reasoning  tools  to  reduce  the 
user’s  adaptation  and  selection  workload, 

•  software  composition  teduiology  to  construct  ana¬ 
lyses,  models,  simulations  and  real-time  software 


PreceeaStap 

EinptiMls  on 

1.  Bound  the  Domain 

2.  Deftne  Domain  Spedflc  Concepts 

3.  Deflne  implementation  Constraints 

4.  Develop  Domain  Architecture 

5.  Produce  Reusable  Workproducts 

User's  needs 
Problem  space 
Solution  space 
Module  Interfaces 
Implementation 

Flgart  2.  Oemein  Antlyslt  riotess.  The  Mpsrstton  of  pfoMom- 
eomsln  analysis  from  somtlon-eomaln  analysis  Is  a  Slstln- 
gulsMng  fsatura  of  this  process. 


Flgura  3.  Pilot  In  Um  loop  nyotom.  Tho  top  ImI  vIom  (a)  of  an  intasratod  avionica  tyatam  can  bo  dapiclad  at  a  tanat  of  laynra  that  trantfonn 
raw  tanior  data  Into  control  tisnali.  A  critical  foatura  It  tho  ability  to  oomblna  data  from  a  divartity  of  data  teurcat  (b) 


The  domain  analytU  proctu  begini  hy  bounding  the 
domain  and  by  letting  goala  for  the  analytii  with  the 
objective  of  defining  an  architecture  and  a  tet  of  compo¬ 
nent!  that  cover  a  sufficiently  large  portion  of  the 
domain  to  significantly  improve  productivity  and  quality 
for  avionics  applications.  The  process  then  moves  to 
defining  the  domain-specific  concepts  within  the  previ¬ 
ously  established  bounds.  This  step's  objective  is  to 
determine  the  central  definition  for  the  bounded  portion 
of  the  domain.  Once  the  features  have  been  defined,  the 
remaining  challenge,  before  designing  the  architecture 
and  the  components  themselves,  is  to  define  the  imple¬ 
mentation  constraints.  A  primary  activity  during  this 
phase  is  to  quantify  the  range  of  configurability.  At  the 
highest  level  of  configurability,  the  analyst  needs  to  clas¬ 
sify  features  as  required,  optional,  or  alternative.  The 
final  process  steps,  developing  the  domain  architecture 
and  producing  reusable  workproducts,  are  the  pro¬ 
duction  side  of  the  process.  They  focus  on  defining 
interfaces,  processing  and  configurability  mechanisms 
that  satisfy  the  requirements  ttnd  constraints  defined  in 
earlier  steps. 


f>nmmm  Amafysu  Kttuhs 

Ihe  doif.iia  analysis  has  resulted  in  the  specification  of 
hig^:!  h'.d  Navigation,  Guidance,  and  Flight  Director 
archi...'mires(8ee  Figure  3.)  The  capabilities  required  for 
providing  aircraft  flight  path  management  were  assessed 
and  allocated  baaed  on  DSSA-ADAGE  developed 
object-oriented  d^nitions.  An  additional  component. 
Data  Source  Object  Driver,  was  identified  as  a  neces¬ 
sary  part  of  the  Navigation  domain.  Appropriately,  a 
Data  Source  Object  Device  Driver  architecture  has  been 
defined. 


The  Navigation  component  determines  aircraft  position 
relative  to  one  or  more  reference  frames.  This 
component’s  primary  ftinctions  are  to  model  the 
aircraft's  operating  environment  and  to  integrate  diverse 
sensor  measurements  into  a  single  estimate.  The  current 
architecture  permits  the  navigation  component  to  adapt 
to  a  variety  of  data  sources,  filters,  gains  and  earth  and 
atmospheric  modda. 

The  Cuidtuice  component  determines  the  diSerence 
between  mission  objectives  and  current  aircraft  state.  It 
calculates  a  desired  flight  profile,  estimates  error  in 
heading,  speed  and/or  altitude,  and  assures  smooth  tran¬ 
sitions  b^een  modes.  The  guidance  architecture 
permits  the  guidance  component  to  select  the  required 
modes,  filters  and  gains,  and  to  specify  mode  precondi¬ 
tions  such  as  data  quality,  capture  criteria,  and  mode 
conflicts. 

The  purpose  of  the  Flight  Director  is  to  convert  guid¬ 
ance  errors  into  pilot  control  cues  or  autopilot  com¬ 
mands.  Its  primary  function  is  to  develop  cues  based  on 
errors,  aircraft  performance  models  and  pilot  models. 
As  designed,  the  architecture  can  accommodate  fixed  or 
rotary  winged  aircraft  parameters,  varying  aircraft  flight 
models  and  pilot  models,  and  different  sets  of  control 
laws  and  gains. 

The  investigation  of  the  aircraft  navigation  application 
domain  has  yielded  systems  with  widely  ranging  system 
performance  requirements,  physical  data  sources,  and 
real  time  processing  requiremmts.  Therefore,  it  was 
determined  that  a  Navigation  component  reconfigurable 
design  must  incorporate  a  component  that  was  capable 
of  converting  de^ce  specific  data  and  protocols  to 
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Mandard  fonnata.  Tbi*  component,  the  Data  Source 
Object  Device  Driver,  acta  aa  a  buffer  between  the  phya- 
ical  data  aouroaa  and  tha  navigalioa  component  Ita 
primary  fVmctiona  are  to  aequence  through  the  legal 
atatea,  monitor  correct  operation  and  control  the  phya- 
ical  device.  Thia  component  ia  deeigned  to  aelect  from  a 
variety  of  Amcdona,  define  device  formala  and  protocola, 
select  sampling  rates,  select  fibers  and  constants,  and 
define  quality  criteria. 

4.0  AVIONiCS/ARCHlTECTURE  KNOWLEDGE 
REPRESENTATION  LANGUAGE 

Languagt  is  a  rtfleetion  of  a  porasBgm  withui  a 

domain. 

—  John  GoodenoughCS] 

Integrated  avionics  is  an  evolving  domain  challenged  by 
the  twin  demands  of  expanding  missions  and  advanced 
system  architectures.  The  concepts  used  in  avionics, 
however,  are  mature  and  well-understood  leading  to  the 
conclusion  that  they  can  be  ftirther  codified  to  support 
automated  construction  of  avionics  systems.  While  this 
notion  is  appealing,  it  ignores  the  problem  that  avionics 
luiowledge  encompasses  a  wealth  of  information  from 
many  disciplines.  A  design  team  coordinates  knowledge 
of  control  theory,  real-time  scheduling,  human  factors, 
electrical  design,  and  many  other  disciplines  to  translate 
customer  needs  into  a  working  system.  To  coordinate 
this  information  a  suitable  language  or  coordinated  set 
of  domain-specific  sublanguages  must  be  used. 

A  sublanguage  can  be  thought  of  as  a  way  of  expressing 
a  user’s  point  of  view.  Depending  on  the  sublanguage, 
the  statements  can  covey  both  formal  and  informal 
information  about  a  system.  A  requirements  cross- 
reference  quickly  asserts  the  satisfaction  of  customer 
needs.  A  system  block  diagram  easily,  but  informally, 
identifies  the  system's  hardware  and  software  compo¬ 
nents  and  their  inter-connections.  To  a  control  engineer, 
control  block  diagrams  are  a  more  formal,  well- 
understood  way  of  describing  an  algorithm.  Finally, 
programming  statements  most  formally  express  an  algo¬ 
rithm  at  the  expense  of  induding  targe  amounts  of 
implementation  details  that  often  limit  a  reader’s  under¬ 
standing.  These  different  views  of  a  system  are,  in  a 
sense,  complementary.  While  they  include  some  of  the 
same  information,  they  also  indude  different  information 
appropriate  to  their  levels  and  uses.  Each  is  best  under¬ 
stood  by  a  different  member  of  the  design  team.  In  the 
end,  however,  they  must  describe  the  same  system. 

The  separate  sublanguages,  or  views,  need  to  exist  so 
each  discipline  can  express  its  aspects  of  the  system  in  a 
familiar  or  comfortable  notation.  From  a  language 
point  of  view,  the  creation  of  a  system  from  a  domain- 
specific  software  architecture  can  be  expressed  by  the 
equation: 

n 

System  =  DSSAo  y  DomainJStatements^^ 

(-1 


ADAGE'S  domain  analysis  has  brought  out  several  con- 
dusions  regarding  the  types  of  knowledge  that  should  be 
collected  and  bow  they  should  be  used.  ADAGE  has 
focussed  on  the  languages  and  tools  that  would  assist  an 
expert  avionics  engincar  by  eUminaiing  many  error- 
prone  and  medianicai  steps  in  converting  requirements 
into  programs.  ADAGE  is  designing  formal  languages 
for  two  purposes:  to  express  the  concepts  embodied  by 
the  avionics-specific  software  architecture,  and  to  form 
the  basis  for  automation.  Having  formally  specified  the 
concepts  allows  avionics  designers: 

•  to  analyze  the  static  aspects  of  the  reference  archi¬ 
tecture, 

•  to  tee  if  the  correct  dass  of  systems  can  be  con¬ 
structed, 

•  to  determine  if  the  right  details  are  described,  and 

•  to  see  if  the  descriptions  easy  to  use. 

This  section  outlines  key  dements  of  ADAGE’S 
Avionics/Architecture  Knosvledge  Representation  Lan¬ 
guage  (AKRL).  Rather  than  giving  a  detailed 
description  of  all  its  features,  it  focuses  on  those  areas 
that  are  important  to  the  avionics  domain.  It  is  subdi¬ 
vided  into  sections  that  describe  the  organization  of 
avionics  knowledge  into  three  views;  the  analyst’s 
problem  view,  that  devdops  strategies  to  meet  customer 
needs;  the  architecture  solution  view,  that  converts  the 
strategies  into  designs;  and  the  architecture  implementa¬ 
tion  view,  that  implements  the  design.  One  or  more  sub¬ 
languages  are  required  to  describe  each  of  these  aspects 
of  an  avionics  system.  These  sublanguages  are  designed 
to  have  both  textural  and  graphic  representations  that 
speak  in  terms  appropriate  to  their  users. 


4.1  Analysfs  FroUem  Fin* 

The  highest  levd  view  of  a  system,  the  description  of  the 
strategies  used  to  satisiy  requirements,  contains  the 
broadest  and  deepest  knowledge.  While  it  is  clearly 
infeasible  with  the  state  of  the  art  to  automatically  design 
an  avionics  system  by  simply  evaluating  customer  needs, 
it  is  appropriate  to  capture  strategies  used  by  expert 
designers.  Since  an  avionics  software  architecture 
embodies  a  class  of  avionics  solutions,  the  way  each 
system  uses  it  to  satisfy  its  requirements  may  vary. 
ADAGE  needs  a  way  to  record  how  designers  have 
used  the  architecture  to  meet  typical  requirements.  The 
information  include*  a  customer’s  ne<d  (an  issue),  a 
description  of  one  or  more  alternate  ways  to  solve  it  (a 
set  of  position*)  and  rationale  about  when  each  strategy 
should  be  used  or  when  it  another  is  preferable  (argu¬ 
ments). 

ADAGE  is  using  the  Issue  Based  Information  System 
(1BIS)[6]  notation  to  record  the  problem  view  of  the 
avionic*  syttem(tee  Figure  4).  IBIS  describe*  a  network 
of  information  that  build*  evidoice  for  taking  positions 
on  issues.  This  information  can  be  used  to  provide 
genwal  guidance  to  the  avionics  designer  for  considering 
alternative  designs.  It  also  can  provide  a  checklist  of 
typical  solutions  that  define  an  organization's  product 
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ISSUE  1:  R<E«lr«E  sttUIoii  tmort 

POSItI(M_I:  4  Ckimtl  VS 
AMUMEIT'i:  Mifcly  Accunt*  1*4  4w<  Mt  nsuirt 
POSlTinj:  1  Ckamtl  H>S  u4  ItS 
MNUMEsO:  HI  Shi  y  Accuntt  but  rtsulrti  ansthtr 
POSITin's:  m  anU  Uttr  Altlaattr 
P0SITin''4:  m  tnU  RiAtr  AUlHtar 
AMIMUO:  S4a4  accuracy  rasulrad 
AMIMEhT_4;  Caucrt  opapatla*  rasuirth 


nsura  4.  SubhM  IBIS  4McrlpHM  of  anaer  aalaelloii.  SIBIS 
Sraphleit  notittan  allow*  uaar*  to  Mlow  argu/noni*  tnd 
poaitlon*  cancanHiis  doalgn  laauao.  Tho  taaoual 
raproaontalon  con  ho  roadlly  updoMd  or  Indudod  In  tho 
Uoalgn  ratlonaloi 

line.  Usen  are  not  limited  to  accepting  the  dictates  of 
pMt  qntenu.  When  new  requirements  or  new  algo¬ 
rithms  become  available,  designers  are  fiee  to  add  new 
issues,  positions,  or  supporting  arguments  to  the  know¬ 
ledge  bm. 


dsAnad  as  a  reo/m  of  plug-compatible  components.  AH 
members  of  the  realm  arc  requirwl  to  output  data  of  the 
same  type  although  they  may  input  dsita  of  different 
types.  ADAGE'S  portion  of  the  avionics  domain  is  con- 
caaned  snth  estimating  aircraft  state  based  on  a  suite  of 
sensors,  a  set  of  mission  objectives,  a  cottccdon  of  fil¬ 
tering  algorithms  and  their  relationships.  The  system 
has  been  represented  as  a  set  of  layers,  from  data 
sources  at  the  bottom,  through  navigation,  to  guidance 
and  flight  director  at  the  top.  Each  layer,  transforms  its 
data  into  a  form  usable  by  the  next  higher  layer.  For 
example,  each  sensor  reports  the  raw  data  in  its  oem 
coortfinate  frame.  The  data  source  layer  converts  the 
raw  data  to  a  standard  aircraft  state  estimate  in  a 
common  coordinate  frame.  The  navigation  layer  refines 
the  estimates  into  a  system  estimate  with  respect  to  the 
coordinate  frames  needed  by  guidance  and  by  the  crew. 


In  the  case  of  navigation,  the  realm  defines  the  stages  of 
sensor  data  combination  and  filtering  that  can  be  inte¬ 
grated  into  the  system.  The  example  bdow  shows  a  sim¬ 
plified  subset  of  the  navigation  realm. 

NAV  •  {derived  data[1:INAV],...} 

IMAV  -  {conpf11ter[1;INAV.d:DPLR],... 
auto_se1ect1on[i :{INAV}], 
gps_1ns[g:GPS,i:INS],... 
dpir  in$[d:DPLR,1:lNS],..., 
gp$[g;GPS],  ins[l:INS]....} 


In  the  ADAGE  environment  the  designers'  decisions 
and  thdr  rationale  are  recorded  automatically.  This 
high-level  rationale  is  reported  as  documentation  for 
peer  reviews  and  for  long-term  maintenance. 


4J  ArdUUetmt  Jsfrtfisa  Fitw 

Architectures  have  often  been  depicted  by  layer  dia¬ 
grams,  data-flow  diagrams  or  block  diagrams.  Propo¬ 
nents  of  Object-oriented  Analysis[7,  8]  (OOA)  have 
developed  means  of  describing  the  classts  of  obiteu  in  a 
domain  and  their  operations,  associatiom  between  them 
and  the  constraints  upon  them.  Their  notations  create  a 
model  of  the  domain  data  that  represents  a  portion  of  a 
expert's  knowledge.  ADAGE'S  domain  analysis  used  a 
combination  of  two  object-oriented  analysis 
techniques[4,  9].  It  identified  classes,  associations  and 
constraints  for  the  integrated  avionics  domain.  Rather 
than  using  an  existing  notation,  the  objects  in  its 
avionics  wchitecture  have  been  represented  by  equiv¬ 
alent  notations  that  can  be  understood  by  the  ADAGE 
environment. 

The  first  part  of  the  archilectiire  represents  the  classes  of 
avionics  objects,  the  constraints  on  their  number  and 
their  data  type  dependencies.  ADAGE  uses  a  set  of 
paramtteristd  typt  expressions,^  ,  to  define  a  layered 
view  of  the  ardiitccture.  Each  layer  in  the  system  is 


It  states  that  NAV  contains,  among  other  things,  an  algo¬ 
rithm  for  deriving  earth-referenced  aircraft  state 
parameterized  by  the  realm  of  internal  navigation  data 
INAV.  It  also  states  that  the  data  type  output  by  INAV 
can  be  created  by  an  INS,  by  a  GPS,  or  by  some  com¬ 
bination  of  the  two.  The  ellipses  indicate  this  example 
only  defines  a  subset  of  the  components  in  these  realms. 
An  interesting  feature  of  type  expressions  is  that  compo¬ 
nents  in  a  realm  may  be  reflexive,  i.e.,  they  take  as  input 
other  components  in  the  realm.  In  the  example  above, 
the  conpfilter  can  take  any  INAV  output  and  combine  it 
with  a  OPLR  before  outputting  another  INAV  ouqsuL  As 
an  example,  the  expression  in  Figure  S  describes  a 
simple  system  in  which  the  reflexive  component 
auto_se1cct1on  chooses  among  three  INAV  components, 
at  run-time,  before  passing  the  result  to  derl  ved_datB. 

Object  classes  and  layering  type  dependencies  are  not 
sufficient  to  describe  the  architecture  at  this  level.  The 
type  expressions  lack  a  means  for  describing  the  data 
flow  between  components  (ftmctional  model  in  OOA 
terms)  including  temporal  (throughput  and  consistency) 
requirements  between  components  and  the  quality  of  the 
data  on  the  interfaces.  The  software  circuit 
paradigmC12],  developed  by  David  McAHester  of  tiie 
Massachusetts  Institute  of  Technology,  defines  con¬ 
straints  between  components  in  an  analogy  based  on 
clock  and  data  wires  in  electronic  circuits.  Using  the 
circuit  definition,  the  ADAGE  environment  can  perform 
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1  Ths  cmcepts  of  paramettrlitd  type  expreuion,  realm  and  r^batve  componsnr  wars  davciopad  by  Don  Bstory  from  tha  University 
of  Texas  at  Austin  on  tbs  Oenasis  projaet[10,  1 1]. 
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(a)T«ilMl  viaw 

Slnvlt.lMV  • 

[dtrl vtd_data 
[c«Bp_f11t«r 
[•uto_»#1«ct1on 
[9pi_1  ns  [S«m_GPS ,  SaiM_I  NS] . 
9PsIs<iM_6PSl, 
insCSom  INS]]]]. 
dns[S0Mt_DNS] 


(b)  Hurarcliical  vww 


FIfura  S.  Typa  IxsnMlom.  ADAGE  grapMcal  uMr  lirtarfaot  tool* 
convart  tha  ttMlual  notatton  Into  a  mora  raadaMa  farm. 
Whila  tha  tha  ADAGE  taolt  uta  tha  taatual  notation  (a)  to 
Oaacrlba  tha  layartns  of  tha  arehitactura.  utara  prafOr  data 
now  dlagraniA  hiararchy  chatta  (b)  and  manua. 

several  analyses.  First,  it  can  check  that  the  drciiit 
obeys  design  completeneu  and  consistency  rules.  It  can 
construct  models  of  the  noise  present  in  the  estiinatea  of 
real  arorld  parameters  such  as  the  aircraft  estimated 
state.  Finally,  using  models  of  execudon  times,  it  can 
vcriiy  real-time  performance  requirements.  These  con¬ 
straints  were  si^ed  out  because  the  domain  analysis 
indicated  that  they  would  provide  the  greatest  benefit  to 
the  developers.  For  exai^e,  the  combination  of  per¬ 
formance  and  noise  modeling  will  permit  ADAGE  to 
suggest  certain  components  would  be  more  suitable  than 
others  for  a  given  design.  Performance  modeling 
coupled  with  lower  level  scheduling  paradigms  (e.g.. 
Rate  Monotonic,  Earliest  Deadline,  Cyclic)  would  spot 
timing  problems  before  the  system  M  the  designer's 
desk. 

There  are  many  ofiier  constraints  that  exist  at  the 
analyst’s  level  view  of  an  architecture.  Even  a  simple 
constraint  such  as  Terrain  Following  requires  a 
forward-looking  altitude  data  source  with  a  range  of 
[aircraft^spedfic]  miles  and  and  accuracy  of  [x]” 
defines  fimctional  dependency  between  components, 
constraints  on  the  attributes  of  components  and  depend¬ 
encies  between  components  and  system  models. 
ADAGE  uses  Ontic[13],  a  language  for  describing 
mathematical  concepts,  system  specifications,  implemen¬ 
tations,  and  verifications,  both  to  implement  the  circuit 
compiler  and  to  represent  first-order  logic  constraints  on 
architectural  elements.  One  of  Ontic’s  primary  advan¬ 
tages  is  that  statements  written  in  the  language  can  be 
evaluated  using  a  non-deterministic  version  of  LISP. 
Therefore,  flw  ADAGE'S  constraint-based  reasoning 
system  can  evaluaie  Ontic  descriptions  of  constraints  to 


assist  the  user,  via  the  ADAGE  graphical  user  interface, 
in  selfirting  models,  components  and  numerical 
paramenlars.  Smoe  the  syntax  of  the  language  is  dose 
to  LISP  and  since  the  expressions  deal  with  low-level 
details  of  the  architecture,  the  application  developer  will 
not  interact  dfaectiy  erith  the  On&  representation. 


4J  AidUltrtme  hmphmmMitn  Fiew 
Perhaps  the  most  important  concept  in  object-oiientad 
analysis  is  the  definition  of  the  dw  inheritance  hier¬ 
archy.  ADAGE  uses  LILEANNA[14],  developed  by 
Win  Traez  of  IBM,  to  spediy  class  hicrarchiss  and  to 
compose  them  into  Ada  packages.  LILEANNA  —  LIL 
Extended  entb  ANNA  (Annotated  Ada)  —  is  a  module 
composition  language  for  designing,  structuring,  com¬ 
posing,  and  generating  softerare  systems  in  Ada. 
LILEANNA  extends  Ada  by  introducing  two  entitias: 
theariu  and  viewtr,  and  by  enhancing  a  third,  padtage 
spedfications.  A  LILEANNA  package,  erith  semantics 
specified  either  formally  or  informally,  represents  a  tem¬ 
plate  for  actual  Ada  package  sperifiralions.  It  is  used  as 
the  common  parent  for  famiKes  of  implementations  and 
for  version  control.  A  theory  is  a  Ughcr-levd 
abstraction  (a  concept),  that  describes  a  module’s  syn¬ 
tactical  and  semantic  interface.  A  view  is  a  mapping 
betereen  qrpes,  operations,  and  exceptions. 

Programs  can  be  stnictured  and  composed  using  two 
types  of  hierarchies:  vertical  Oevels  of  abstraction  and 
stratification)  and  korixontal  (aggregation  and 
inheritance).  LILEANNA  supports  this  with  two  lan¬ 
guage  medianiams:  import  dtqscndencies  called  needs 
and  three  ftmns  of  inheritance  called  import,  protect, 
and  extend. 

Figure  6  demonstrates  bow  ADAGE  uses  tome  of  these 
features  to  represent  avionics  concepts.  Integrated 
avionics  systems  often  require  a  data  selection  mech¬ 
anism  based  on  the  quality  of  data  Grom  the  input 
sources.  There  are,  however,  many  ways  of  describ^ 
the  quality  of  information  coming  from  a  data  source. 
Rather  dian  coercing  users  into  choosing  one  represen¬ 
tation,  ADAGE  defines  a  theory  of  data  quality.  This 
permits  the  architecture  to  define  dements  that  depend 
on  the  existence  of  the  concept  of  data  quality  wiftout 
burdening  them  with  ‘t—Mn  of  any  one  implementation. 
In  the  class  hierarchy  the  theories  of  data  quality  and 
the  aircraft  state  vector  are  merged  to  create  the  concept 
of  measured  state  i.e.,  an  estimate  of  the  aircraft's  posi¬ 
tion,  vdodty  and  attitude  as  measured  and  qualified  by 
a  data  source.  The  diagram  shows  just  one  use 
measured  state,  its  input  to  sdection  routines  to  dioose 
the  appropriate  source  for  a  particular  dement  of  the 
state  vector.  To  create  an  automatic  sdection  routine,  a 
user  would  chose  one  of  the  sdection  routines,  e.g., 
automatic  regresdon,  and  one  modd  of  data  quality. 
The  software  composition  tools  in  ADAGE  would  col¬ 
lapse  the  class  Uerarchies  to  produce  an  optimized 
regresdon  routine. 


[ 


There  is  a  dear  mapping  from  LILEANNA's 
formdisnis  to  the  parameterixed  type  exprestiom  dis- 
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cuM«d  earlier.  LILEANNA  packaget  and  theorus  cor- 
reapond  to  realms.  with  the  exception  that,  in 
LILEANNA,  the  software  composition  mechanisms 
inheritance  and  parameterization)  are  explidt 


LILEANNA  contains  a  second  feature  not  found  in 
parameteraed  type  expressUuts  -  ANNA[IS,  16]. 
ANNA  lets  users  define  behavior  in  terms  of  first-order 
predicate  logic.  Behavior  statements  can  speeiiy  invari¬ 
ants  and  constraints  on  any  level  of  object  fixun  a  theory 
down  to  a  Ada  package.  The  behavior  can  be  validated 
at  run-time  bocause  the  ANNA  tools  translate  the 
assertions  into  pre-condition  and  post-condition 
checking  code.  Since  all  constraints  cannot  be  verified 
at  design  time.  The  ADAGE  environment  intends  to  use 
ANNA  to  support  algorithm  validation  during  desktop 
simulations.  The  run-time  checks  can  be  dimiiuted  for 
the  real-fime  embedded  system. 


5.0  SUMMARY 

Domain-specific  software  architectures  can  provide  the 
structure  for  the  improved  automation  of  integrated 
avionics  systems  development  They  can  facilitate  megm 
/vagr«Miaipg[17]  —  the  proccu  of  constructing  software 
one  component  at  a  time,  rather  than  one  line  at  a  time 
The  avionics  domain  ezhitfits  the  attributes  [18]  neces¬ 
sary  to  demonstrate  the  viability  of  this  approach  for 
real-time  system  devdopment  maintenance,  and  evolu¬ 
tion.  Two  challenges  remain.  First  avionics  needs  well- 
engineered  components  that  can  be  readily  adapted  for 
use  in  a  variety  of  airborne  systenu.  In  addition,  to  fitUy 
meet  the  challenge,  there  needs  to  be  an  open  environ¬ 
ment  (ADAGE),  based  on  domain-specific  languages, 
that  organizes  these  components  within  the  context  of  a 
software  architecture  and  provides  analysis  and  synthesis 
toots  to  facilitate  the  mqaprogramming  process. 
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1  •  ENTREPRISE  II  :  THE  DEVELOPMENT 
ENVIRONMENT  FOR  MAJOR  SOFTWARE 

Entrepriae^^ll  users  arc  in  (he  technical  and  scientific 
software  industry  and  include  members  of  software 
development  and  maintenance  teams,  at  all  levels: 
administrators,  project  managers,  project  leaders,  those 
in  charge  of  sub-projects  or  tasks,  developers  and 
maintenance  staff.  Entreprise  n  is  also  designed  for 
software  tool  editors,  who  need  an  integrated  CASE  tools 
environment  in  which  they  can  develop  and  distribute 
their  own  tools. 

Developers  of  software  systems  face  numerous  problems 
directly  related  to  software  development,  upkeep  and 
maintenance.  Entreprise  n  provides  a  solutioa  to  these 
problems,  at  both  organizational  and  technical  levels. 

1.1-  Controlling  the  organizational  factors 

This  involves  defining,  formalizing,  implementing  and 
monitoring  the  development  of  software  applications 
development  to  be  integrated  in  a  system  whose 
installation  requires  complex  structures  and  the 
cooperation  of  specialists  from  different  fields 
(conciment  engineering). 

These  activities  take  place  in  an  industrial  environment 
which  is  heavily  influenced  by  the  following: 

•  world-wide  structure  of  large  organization, 

•  need  for  international  cooperation  between 
organizations, 

•  geographical  distribution  of  development  sites, 

•  difficulty  of  managing  complexity,  organization, 
cost,  production  and  installation  deadlines  of  the 
projects, 

•  diversity  of  prints  and  capabilities  involved  in 
software  production. 


•  diversity  of  projects  undertaken  by  any 
organization. 

1.2-  Controlling  technical  factors 

It  is  important  to  control  the  factors  affecting  software 
developinent  quality  in  the  following  areas  : 

•  increasing  complexity  of  software  applications, 

•  rapid  technological  improvement, 

•  increasing  diversification  of  software 
applications,  which  results  in  ever  greater  demand  and 
consequently  the  need  to  increase  the  developers' 
individual  and  collective  productivity, 

•  extended  life  of  software  applications,  resulting 
in  the  need  to  prolong  the  period  of  software 
maintenance  and  to  increase  investment  in  maintenance. 

•  increasingly  strict  quality  requirements,  due  to  the 
introduction  of  software  in  the  critical  parts  of  sensitive 
or  high-risk  systems. 

1.3-  Controlling  the  maintenance  factors 

The  increase  in  maintenance  activities  is  forcing 
software  developers  to  find  ways  to  automate  and  support 
the  maintenance  tasks.  The  reluctance  of  software 
developers  to  devote  time  to  these  tasks  (they  generally 
prefer  to  focus  on  developinent),  as  well  as  the  lack  of 
qualified  software  developers  to  meet  development 
demands,  contribute  to  the  growing  imbalance  between 
development  and  maintenance.  Large  organizations  have 
to  look  for  solutions  which  improve  automation  of 
development  and  maintenance.  Method  tools, 
formalization  tools  and  support  tools  for  software 
development  and  maintenance  techniques  existing  today 
on  the  market  are  extremely  diverse. 

Therefore,  the  first  problem  to  tackle  in  the  process  of 
automation  is  this  diversity  of  tools,  which  can  be 
overcome  by  modelling  and  formalizing  the  organization 
of  the  development  and  maintenance  processes. 


Presented  at  an  AGARD  Meeting  on  Aerospace  Software  Engineerir^for  Advanced  Systems  Architectures’,  May  1993. 


33-2 


1.4-  CASE  tool*  fragmcatalloa 

The  cunent  range  of  Case  looU  U  characterized  by: 

•  (he  existence  of  varying  and  incompatible  basic 
methodologies, 

•  numerous  differing,  incomplete  and  unrelated 
methods. 

•  a  disorganized  range  of  tool-type  products. 

This  fragmentation  in  methods  and  tools  appears  to  be 
(he  most  serious  factor  hindering  from  production  and 
quality  control.  The  level  of  investment  required  to 
obtain  a  total  solution  may  be  one  reason  for  this 
fragmentation.  Each  tool  supplier  tends  to  limit  itself  to 
solving  problems  relating  to  a  single  part  of  the 
development  process.  Thus  we  find  a  large  number  of 
specification,  design,  programming  and  test  tools,  but  a 
total  lack  of  complete  environments. 

This  situation,  in  turn,  results  in  fragmented  software 
development  practices  and  often  forces  developers  to 
perform  'manuar  transitions  between  phases  in  (he 
software  life  cycle.  For  instance,  the  lack  of  automation 
in  the  transition  between  the  design  and  coding  phases 
means  that  developers  have  to  provide  documents 
proving  (he  progression  of  the  design  phase  and  the 
justification  for  moving  to  the  coding  phase.  These 
documents  form  'links’  and  'reference  points’  between 
phases,  which  should  be  available  for  re-use  in 
.naintenance  phases  or  when  backtracking  from  coding 
to  design.  These  manual  procedures  generally  make  the 
development  process  inefficient  and  also  com|dicate  the 
maintenance  process. 

It  is  essential  to  find  solutions  which  enable  integration 
and  automation  of  the  entire  development  process. 


1.5-  Horizontal  and  vertical  activlllca 

The  software  development  process  includes  two  types  of 
activity: 

•  life-cycle  activities  (simulation,  prototyping, 
specification,  design,  coding  and  testing). 

•  cross-life  cycle  activities  activities  performed 
during  development  (project  management,  configuration 
management,  documentation,  quality,  re-use,  etc.). 


In  order  to  integrate  the  development  process  we  have  to 
define  the  general  frame  for  these  activities  and  in 
particular  decide  which  data  will  be  used  and  by  which 
methods  (be  data  will  be  handled  in  terms  of  rules,  rights 
and  responsibilities.  The  automation  of  the  development 
process  calls  for  the  creation  of  tools  which  can  support 


both  horizontal  and  vertical  activities  and  transitions 
between  activities. 

The  facilities  and  architecture  of  Entreprisc  II  have  been 
designed  to  meet  these  support  requirements  for  the 
whole  range  of  development  and  maintenance  activities 
for  large  software  applications.  The  design  stage 
involved  collaboration  with  a  number  of  major  technical 
French  users  (Thomson  CSF.  Aerospatiale,  Dassault 
Aviation.  Dassault  Electronique,  Sextant  Avionique, 
Sagem,  Sfim)  and  the  Delegation  Generals  pour 
rArmement. 


2-  ENTREPRiSE  II,  A  LAYERED 
ARCHITECTURE 


Entreprise  II  is  based  on  a  layered  architecture.  The  first 
layer  includes  the  software  framework,  providing 
interface  facilities  with  the  various  tools  in  the 
environment  and  complying  with  a  data  communication 
protocol.  The  next  layer  contains  facilities  for 
'integrate*  software  tools.  These  facilities  can  be 
grouped  together  under  the  generic  term  'backplane'.  The 
whole  system  used  to  integrate  CASE  tools  forms  the 
Integrated  Project  Support  Environment  (IPSE).  When 
vertical  software  engineering  tools  of  various  origins  are 
inserted  into  this  open  environment,  it  becomes  a 
Populated  Integrated  Project  Support  Environment 
(PIPSE).  The  system  always  uses  the  same  look  and  feel. 
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3 . 1  •  PCTE:  Tka  EatrapriM  II  loflwara 
fraaiawork 


Tka  ioflwaia  framawork  U  the  communicationi  channel 
for  all  Iha  Enuafaiaa  U  compooenla .  It  utea  the  PCTE  1 .5 
(Portabla  Cominoa  Tool  Eovironmeoi)  iiaodard. 
Eolraprua  □  will  be  ported  to  ECMA/PCTE. 

The  software  framework  is  a  critical  element  for  the 
interaction  of  software  systems,  whether  they  are 
development  environments  or  applications  developed 
and  maintained  using  these  environments.  It  is  essential 
that  the  software  framework  should  act  as  a  standard, 
guaranteeing  long  system  life  and  attracting  suppliers  of 
tools,  environments  and  applications. 


The  software  framework:  the  key  to  system  interaction 

2.2*  The  software  backplane 

The  software  framework  alone,  whilst  essential  for  an 
integrated  environment,  is  not  the  only  prerequisite.  The 
homogeneity  of  the  environment's  methods  and  tools 
requires  compliance  with  a  set  of  principles  and  rules 
implemented  by  the  Entieprise  II  backplane. 

This  backplane  is  supported  by  PCTE  and  makes  it 
possible  to  formalize  the  development-maintenance 
process  ; 

•  integration  of  the  organization  in  the  process, 

•  setting  up  effective  communicatioa  between  all 
teams  and  organizations,  particularly  to  accelerate  the 
decision-making  process, 

•  setting  up  the  means  to  follow  up  and  inspect  the 
development  steps, 

•  adaptation  of  the  methods  and  tools  used  to  the 
specific  requirements  of  the  organization,  projects  and 
individuals, 

•  need  to  integrate  a  coherent  quality  control  policy 
which  aims  to  increase  the  automation  of  inspections. 


All  these  requirements  must  be  solved  within  a  coherent 
frame  fur  which  fouirdatioos  must  be  laid.  This  is  the  role 
of  the  Entreprise  Q  backplane.  Without  this  backplane 
methods  or  tools  usembicd  within  an  environment 
would  be  heterogeneous  and  incoherent. 

PCTE  itself  defines  a  number  of  standard  and  public  data 
schemas.  Entreprise  II  thereby  contructs  a  philosophy 
for  handling  development  and  maintenance.  The 
Entreprise  II  schemas  define  three  types  of  data 
dictionaries: 

•  Nomeitclature  type  dictionary  icovering  all  data 
for  managing  the  IPSE  and  information  concerning 
methods  ; 

•  Encyclopedia  :  for  each  project  developed  in  the 
IPSE  which  contains  all  data  produced  during 
development  and  maintenance; 

•  Reusable  Objects  Data  Dictionary  :  containing  all 
data  which  can  be  re-used  from  one  project  to  the  next. 

2.3-  Managing  the  dialog  with  the  user 

Entreprise  II  is  an  interactive  development  environment. 
The  dialog  is  standardized  whatever  tools  are  employed 
by  the  user. 

When  the  user  connects  to  the  workstation,  he  enters  a 
session,  i.e.  an  environment  composed  of  an  IPSE,  a 
project,  a  task  and  a  role: 

•  at  the  project  level,  Entieprise  D  defines  the  tasks 
on  which  the  user  can  work, 

•  at  the  task  level.  Entreprise  □  determines  whether 
the  user  belongs  to  the  group  of  users  allowed  to 
participate. 

•  at  the  role  level.  Entreprise  U  determines  the 
tools  to  which  the  user  has  access  rights  and  allows  him 
to  customize  the  presentation  of  these  tools. 

These  measures  contribute  to  the  security  of  environment 
functions  according  to  the  following  basic  principle: 

the  only  funcHons  presented  to  a  user  are  those  for  which 
he  is  auihorized. 

One  user  may  be  connected  to  various  tasks  belonging  to 
various  projects  within  a  single  environment.  The  user 
can  only  activate  the  tools  associated  with  the  task  on 
which  he  is  working. 

The  command  language  and  the  graphic  navigator  are 
used  to  navigate  around  the  data  dictionaries  and  activate 
the  tools  (with  a  display  or  graphic  table  for  selection  of 
options  and  start-up  parameters).  Graphics  are  used  for 
dialog  with  the  user.  Expert  users  may  alternatively  use  a 


l«at  command  languat*  for  dialog.  The  look  and  feel  of 
the  EatrepriM  U  dialog  complies  with  the  Molif^^  or 
Open  Look^^  standards.  The  open-ended  design  of 
Entreprise  U's  man/macbine  interface  means  that  it  can 
be  adapted  to  other  look  and  feel  standards. 

Z.4-  Structuring  the  devalapmcnt 

Entreprise  0  enables  its  users  to  base  their  development 
structure  on  four  simple,  yet  powerful  concepts. 

•  the  tree  (root  +  nudes)  built  by  the  user,  which 
forms  the  general  frame.  The  participants  will  look  here 
for  the  information  retjuired  and  will  place  the  objects 
they  produce  in  this  frame. 

•  the  object  sets,  positioned  on  the  tree  nodes. 

•  the  objects,  arranged  in  sets, 

•  the  relationships.  The  user  or  the  tools  used  may 
establish  relations  between  the  three  types  of  entities. 
This  will  be  done  in  accordance  with  the  semantics 
defined  and  in  compliance  with  the  basic  rules  imposed 
by  Entreprise  II. 

These  trees,  sets,  objects  and  relationships  can  also  be 
used  to  define  the  principles  for  navigating  within  the 
project  data  base  (encyclopedia).  The  user  can  add 
attributes  to  these  entities  to  facilitate  navigation  and 
selection. 

This  tree-structure  is  used  for  project  management, 
document  management,  configuration  management,  re¬ 
usable  objects,  specification,  design,  code,  etc.  The 
'tree'  concept  has  enabled  the  creation  of  a  unique 
graphic  display  and  nav-gation  system.  The  system  for 
all  the  functions  of  Entreprise  II.  whether  original  or 
added,  is  independent  of  the  tools  and  very  efficient.  The 
project  methodologies  are  also  based  on  this  model.  In 
fact,  methods  such  as  DoD  2167 A,  001788  or  GAM  T17 
V2  actually  impose  a  tree-structure  organization  of 
developments. 

As  an  example.  Entreprise  II  offers  software  developers 
the  possibility  of  building  their  own  structure  to  conform 
to  the  breakdown  of  the  software  they  have  to  produce.  In 
this  way.  the  reference  tree  used  by  the  project  reflects 
the  software  developed: 

•  the  root  of  the  tree  corresponds  to  the  software, 

•  the  breakdown  of  the  software  into  software 
elements  (and  subsequent  breakdown  of  these  software 
elements  into  other  elements  or  components),  results  in 
the  development  of  the  complete  tree, 

•  the  software  objects  produced  (e.g.  specification 
and  design  documents,  diagrams,  code,  binary  data  etc.) 
are  organized  into  sets  and  positioned  on  this  tree. 


Four  eonctfts  for  o  geoeral  structure 

This  structure,  defined  by  the  user,  is  the  working  basis 
for  all  the  tools  integrated  in  Entreprise  II  Tools  musi 
therefore  position  within  this  structure  all  data  that  can 
be  shared  with  other  tools  This  data  can  be  of  any  type 
(text,  graphics,  images,  etc.) 

2.5-  Controlling  data  access 

The  nomenclature  database  is  used  to  carry  out  a  number 
of  checks  concerning  data  confidentiality  These  checks 
depend  on: 

•  the  data  schemas,  loaded  at  connection,  which 
define  the  user's  view  of  the  project  data  dictionaries 

•  the  tools  available  to  the  user  during  a  session. 

•  the  access  rights  used  by  the  tools  to  control  user 
action, 

•  the  user's  access  rights. 

This  security  also  helps  to  increase  productivity,  as  it 
eliminates  many  types  of  potential  errors. 

2.6-  Managing  the  versions 

The  encyclopedia  database  associated  with  each  project 
contains  all  the  objects  produced  during  the  project 
(documentation,  sources,  binary  data,  technical  notes, 
etc.).  A  standard  data  set  is  associated  with  each  object  in 
the  encyclopedia.  Each  tool  or  user  can  customize  its/his 
view  of  the  objects  by  defining  and  adding  the  data  and 
relations  it/he  requires.  The  following  basic  functions  are 
available  to  the  user  for  handli.ig  trees,  sets,  and  objects: 

•  editing,  for  modifying  an  entity. 

•  stabilization,  for  prohibiting  modification  of 
selected  entities. 

•  duplication,  which  allows  several  users  to  work 
simultaneously  on  the  same  entities. 

•  synchronization/delivery,  which  keeps  the  user 
informed  of  modifications  performed  on  these  duplicated 
entities  by  other  users. 
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Tbe*e  functions  provide  coherent  version  manasement  in 
all  development  activities,  refardless  of  the  type  of 
objects  handled  by  users. 

2.7-  AdmlnUlcrinc  the  IPSE 

Entreprise  11  is  used  for  administration  of  the 
environment,  managing  security  and  confidentiality  of 
all  the  components  (methods,  tools,  participants, 
products,  etc.). 

The  backplane  is  the  host  structure  for  CASE  tools  used 
in  the  environment.  It  defines  the  general  ftame  for  the 
development  and  maintenance  processes,  including: 

*  method  :  before  using  Entreprise  O,  the  project 
leader  defmes  the  methodological  frame  for  development, 
which  allows  the  environment  to  be  configured 
accordingly.  Entreprise  D  can  be  used  for  all  standard 
methods  and  also  allows  the  project  leader  to  define  his 
own  method.  The  incorporated  default  methods  are  GAM, 
T17  (V2).  MIL-STD  DoD  2167A  and  DO  178B. 

*  organization  of  the  software  life  cycle, 

*  company  and  team  practice. 

*  tools  used  in  the  different  phases  of  the  software 
life  cycle, 

*  man/machine  interface:  Motif  or  Open  Look' 

TM 

based  on  the  X.  WINDOW  standard. 

3  •  FEATURES  OF  ENTREPRISE  II  IPSE 

The  Entreprise  n  integrator  development  environment 
supports  the  facilities  which  are  common  to  all  phases  of 
the  software  life  cycle.  The  three  main  productivity 
factors  in  major  software  projects  are  configuration 
management,  documentation  management  and  project 
management. 

3.1-  The  Configuration  Manager 

Configuration  management  means  management  of 
product  versions  at  the  development  stage  (changes),  or 
maintenance  stage  (evolutions).  The  Configuration 
Manager  is  used  to  automate  the  following: 

*  configuration  of  all  or  part  of  the  software 
(definition  of  a  version). 

*  generation  of  a  version. 

*  consultation  of  a  version, 

*  management  and  archiving  of  versions  (history, 
dependency,  etc.). 


The  following  four  types  of  standard  entity  are  provided 
for  managing  modifications: 

•  software  problems  reports  sent  by  end-users  of  a 
version.  Incorporation  of  modifications  to  response  to 
these  reports  can  be  refused,  delayed,  or  accepted. 

•  evolution  requests  intended  for  the  maintenance 
teams.  These  requests  represent  requests  for  modification 
that  have  been  accepted. 

•  change  requests  attached  to  a  version,  which 
include  all  modification  sheets  incorporated  during  the 
development  of  a  version. 

•  modification  sheets. 

The  Configuration  Manager  can  be  used  for  all  indusuial 
methods  and  practices.  It  allows  the  user  to  trigger 
operations  (defined  by  the  user)  when  the  status  of  these 
entities  changes.  It  also  allows  the  user  to  define  other 
types  of  entities  and  other  statuses  or  types  of  transition 
between  statuses. 

These  customization  possibilities,  which  are  vital  for 
incorporating  the  specific  characteristics  of  each 
company  or  project,  makes  the  configuration 
management  tool  the  prized  partner  of  software 
maintenance  teams. 

3.2-  The  Traceabiilly  tool 

The  Tracability  tool  allows  software  modules  to  be 
followed  throughout  the  different  phases  of  their  life 
cycle.  The  Tracker  provides  a  horizontal  view  of  software 
production,  through  the  various  tools  used  for 
specification,  design,  coding,  and  tests.  It  is  particularly 
valuable  for  tracking  software  specifications  throughout 
the  different  stages  of  development,  i.e.  for  recognizing 
to  which  part  of  the  specifications  a  development  object 
(e.g.  design  diagram  or  code  part)  is  related. 

3.3-  The  DocuroeDtatlon  Manager 

The  Documentation  Manager  automates  production  and 
management  of  the  technical  documentation  relating  to  a 
project.  Where  a  certain  development  method  has  been 
associated  with  a  project,  a  documentation  diagram 
allows  the  documentation  to  be  automatically  structured 
according  to  the  same  method,  using  the  software 
breakdown  tree. 

The  Documentation  Manager  automates  document 
production  and  ensures  its  coherence,  using  standard  DTP 
(Desktop  publishing)  tools.  The  Documentation 

TM 

Manager  tool  currently  uses  TPS  and/or 
TM 

Framemaker  tools,  as  selected  by  the  user.  It  is  an 
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open  syilem.  allowing  otber  tooli  (o  be  inlegrated.  u 
required  by  ibe  user. 

3.4-  The  Project  manager 

The  Project  Manager  cool  providea  help  with  all  project 
supervision  tasks,  using  environment  data: 

•  structuring, 

•  organization, 

•  estimation, 

•  planning, 

•  scheduling, 

•  follow-up. 

TM 

The  Project  Manager  is  interfaced  with  the  ARI'EMIS 
product  which  may  be  used  as  a  project  management  tool 
for  the  system  featuring  the  software  developed  or 
maintained  using  Enlreprise  U. 


defined  when  a  compilation  technology  it  connected  to 
the  production  tool.  It  manages  the  program  productioo 
environment,  e  g.  checking  the  presence  of  library 
interfaces  for  the  production  of  ADA  binary  data,  or  that 
files  returned  to  a  C  source  by  tiitclude  commands  are 
present. 

The  Entreprise  11  production  tool  is  an  open  system, 
allowing  various  compilation  technologies  to  be 
integrated.  The  list  of  technologies  integrated  to  far  it 
not  exhaustive  -  other  technologies  will  be  integrated  to 
meet  the  needs  of  users. 

3.4-  The  Reusable  Object  Dictionary 

Sometimes  some  objects  (source  programs,  document 
frames)  developed  during  one  project  need  be  reused  for 
another  project  and  stored  in  a  specific  data  dictionary. 
The  Reusable  Object  Dictionary  manages  objects 
common  to  all  projects  in  the  environment  Its  data  are 
stored  using  a  theme  tree.  Facilities  available  are: 

•  archiving,  which  allows  the  recording  of  objects 
considered  to  be  re-usable. 


The  integration  of  ARTEMIS  in  Entreprise  II  enables  data 
to  be  exchanged  between  the  two  environments  and 
checked  for  consistency. 

3.5-  Code  production 

Coding  activity  depends  not  only  on  the  programming 
methods  but  above  all  on  the  programming  language  and 
the  production  technology  used  (editors,  compilers, 
linkers,  loaders,  symbolic  language  debugger,  library 
manager,  etc).  With  the  Entreprise  II  production  tool, 
coding  activities  do  not  depend  on  the  production 
technology  used,  as  its  programming  environment 
provides  coherence  bet  een  the  different  tools. 


•  consultation  of  the  dictionary,  with  a  search 
function  for  selecting  re-usable  objects, 

•  extraction,  which  allows  the  re-usable  objects 
selected  to  be  inserted  in  the  current  project 
encyclopedia. 

This  tool  forms  the  basis  for  software  re-use  operations, 

3.7-  The  Communication  Manager 

Three  levels  of  communication  are  provided  by 
Entreprise  11: 


Entreprise  II  currently  integrates  various  production 
(compilation)  technologies  for  ADA,  C,  C++  and  LTR  3 
languages.  It  provides  the  programmer  with  a  source 
organization  model  which  is  independent  of  the 
programming  language  used.  It  gives  programmers  the 
means  to  navigate  and  graphically  display  the  source 
texts  of  code  objects.  It  stores  in  memory  the 
relationships  existing  between  source  objects  (at  input) 
and/or  binary  data  (after  compilation)  for  one 
application.  It  ensures,  if  required,  consistency  between 
all  application  objects. 

For  all  programming  languages  supported,  it  provides 
compilation  or  automatic  re-compilation  of  the 
application.  It  automatically  creates  executable 
applications.  It  provides  the  programmer  with  a  powerful 
multi-language  syntax  editor  for  inputting  his  source 
objects  free  of  syntax  errors.  It  manages  interdependency 
of  source  objects  (ADA.  C++.  C.  LTR3,  etc.)  so  that 
transformations  (editions,  compilations,  etc.)  can  be 
applied.  These  language-specific  transformations  are 


*  E-mail  between  users  (software  development  or 
maintenance  teams)  working  on  the  same  project  or  on 
different  projects  in  the  same  IPSE. 

*  composition,  broadcasting  to  lists  of  users  and 
display  of  notes,  agendas,  minutes  of 

meetings,  etc... 

«  communication  of  objects  between  project 
databases  located  in  remote  installations. 


This  set  of  tools  provides  the  developer  with  a  real  office 
system  environment. 


4  -  FEATURES  OF  THE  PIPSE 

Entreprise  II  covers  all  phases  of  a  software  product’s 
life.  It  is  an  environment  open  to  all  types  of  vertical 
tools  and  standardizes  currently  available  horizontal 
tools.  There  are  two  methods  of  integrating  CASE  tools 
into  the  backplane  : 


•  kMMe  ioM(ratioii, 

•  ti|ht  inUgralioo. 

The  backplane  hai  a  ilandard  ‘toolkit*  for  Ioom  and 
tight  integration  of  CASE  tooli.  Thie  allowa  uten  to 
integrate  the  tools  they  wish  to  use  in  Entieprise  0,  snd 
enables  the  horizontal  services  to  be  applied  to  the 
objects  produced  using  these  tools. 

The  operating  dialog  lespects  either  the  Open-Look  or 
Motif  standard,  as  required  by  the  user.  Entreprise  II 
provides  tool  integrators  with  a  module  to  help  them 
design  and  create  these  dialogs. 

Each  tool  uses  in-built  access  rights  to  carry  out  checks 
enabling  it  to  adapt  its  operation  to  the  user's  requests 
and  access  rights.  Entreprise  II  provides  services  for 
developing  interactive  tool  dialogs.  Dialogs  can  thus  be 
created  on  X.Window  which  respect  the  selected  'look 
and  feel*  standard. 

The  Entreprise  U  backplane  thus  offers  a  number  of 
services  for  developing  integrated  vertical  tools, 
including; 

•  a  specific  user  environment 

•  a  dialog  manager 

•  a  window  manager 


•  services  providiog  access  to  data  dictionaries, 

•  all  PCTE  facilities. 

•  an  integrated  command  language  (Shell), 

•  a  graphical  navigator 

Buying  a  new  development  and  maintenance  package  will 
not  mean  that  previous  investments  will  be  wasted,  as 
Entreprise  II  can  host  existing  tools,  making  them 
usable  in  an  Entreprise  11  workbench  without 
implantation  on  PCTE.  For  this,  Entreprise  D  can  be  used 
to  create  host  capsules  (loose  integration).  Entieprise  II 
allows  data  exchange  between  a  project  encyclopedia  and 

TM 

the  host  operating  system  (UNIX  ).  For  example,  host 
system  files  can  be  retrieved  in  an  encyclopaedia,  and 
encyclopaedia  objects  can  be  communicated  to  the  host 
system.  These  exchange  services  are  particularly  useful 
for  hosting  tools. 

Different  software  manufacturers  use  different  vertical 
tools  and  related  methods.  To  allow  for  this,  Entreprise  II 
can  accommodate  all  vertical  tools  required  by  its  users, 
whether  these  tools  are  commercially  available  or  owned 
by  the  manufacturers  themselves.  Entreprise  11  thus 
provides  various  tools  for  simulation,  prototyping, 
specification,  design,  coding,  testing,  maintenance,  etc. 
within  one  project  or  for  different  projects  in  the  same 
IPSE. 


Vertical  tools  in  the  IPSE 
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5  •  ENTREPUSE  II  -  AN  OPEN 
INTEGRATOR  OF  SOFTWARE  ENGINEERING 
SOLUTIONS 

EntreprUe  II  if  the  ideal  enviromnent  for  developing 
medium-  and  large-tize  software. application!  It  is 
typically  used  for  projects  involving  100  000  or  more 
lines  of  code,  where  the  standard  activities  of 
specification,  design,  coding  and  testing  account  for 
only  30%  of  the  total  cost,  the  rest  being  accounted  for 
by  project,  configuration,  documentation  and 
maintenance  management. 

Software  maintenance  accounts  for  more  than  S0%  of  the 
total  cost,  so  integrating  horizontal  tools  used  for 
configuration,  documentation  and  project  management 
with  the  standard  vertical  toots  used  for  specification, 
coding,  etc.results  in  a  30%  increase  in  productivity 
starting  from  the  second  project.  The  vertical  tools 
improve  the  performance  of  individuals  in  their  particular 
production  activity,  while  the  complete,  integrated 
Entreprise  II  environment  works  to  meet  (he  goal  of 
increased  productivity  on  a  higher  level,  i.e.  that  of 
collective  performance. 

Entreprise  II  is  an  open  integrator  of  CASE  solutions. 
The  three  companies  involved  in  the  developement  of 


Entreprise  II  (SYSECA.  CR2A  and  STERIA)  have  set  up  a 
new  company.  EU  Software  which  is  ui  charge  of 
marketing  the  product  This  company  also  has  for  aim  to 
unite  all  CASE  tools  manufacturers  and  retailers  working 
together  with  Entreprise  U  to  give  their  customers  new 
levels  of  productivity,  security  and  long  product  life. 

In  the  USA,  ALSYS  Inc.  is  distributing  Entreprise  II  under 
the  name  of  Freedom  Works'^. 

TRADEMARKS 

ARTEMIS  is  a  registered  trademark  of  Laicas  Management 
Systems 

ENTRERRISE  is  a  registered  trademark  of  The  Mldgation 
Generate  pour  rArmement 

FRAMEMAKER  is  a  registered  trademark  of  Frame 
Technology 

FREEDOMWORKS  is  a  registered  trademark  of  Alsys  Inc. 
MOTIF  is  a  registered  trademark  of  OSF  (Open  Software 
Foundation) 

OPES  LOOK  is  a  registered  trademark  of  AT&T 

TPS  is  a  registered  Uademark  of  Interleaf 

USIX  is  a  registered  Uademaik  of  AT&T 

X.WISDOW  is  a  registered  trademark  of  MIT 

(Massachusetts  Institute  of  Technology) 
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Discussion 

Quesikn  F.  CHERATZU 

What  can  you  say  about  NAM's  (Notth  American  PCTE  Initiative)  intention  of  buildup  and  distributing  for  free  an 
integration  platform  based  on  ECMA  PCTE? 

Reply 

As  far  as  I  know,  but  I  may  not  be  the  right  person  to  answer,  it  seems  to  appear  that  the  objective  of  having  a  NAPI 
public  im|demenlation  of  ECMA  PCTE  is  no  more  pursued.  NAPI  dimter  is  not  yet  completely  established,  so  that  it 
must  be  checked. 

Question  R.  SZYMANSKI 

1 .  Does  the  lack  of  a  validation  suite  for  PCTE  hamper  tool  production  by  the  vendor? 

2.  Which  version  of  the  PCTE  standard  do  you  use? 

Reply 

1.  A  PCTE  1.5  validation  suite  has  been  used  for  Entieprise  Q  validation  by  the  bench  MoD.  There  are  intents  in  the 
North  American  PCTE  Initiative  to  set  up  a  ECMA  PCTE  validation  suiie.  Intents  do  also  exist  within  the  CEC. 

2.  The  initial  version  of  Entreprise  II  is  based  on  PCTE  1.5.  Entteprise  II  will  migrate  very  quickly  to  ECMA  PCTE. 

Question  C.  BENJAMIN 

When  integrating  a  commercial  tool  into  Entieprise  D.  do  you  have  to  do  some  software  modification? 

Reply 

Two  inttgiation  models  are  possible : 

-  a  tight  integration,  where  the  the  tool  uses  directly  the  Entreprise  II  Ftamework  services.  In  that  case,  that  tool  must  be 
modSfied; 

-  a  loose  integration,  wboe  a  'capsule  is  built  around  the  tool,  that  supports  all  the  interface  with  the  bamewoik  and  its 
repository. 
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During  the  past  decade,  many  avionics  functions  which  have  traditionally  been  accomplished  with 
analogue  hardware  technology  are  now  being  accomplished  by  software  residing  in  digital 
computers.  Indeed,  it  is  clear  that  in  future  avionics  systems,  most  of  the  functionality  of  an 
avionics  system  will  reside  in  software.  In  order  to  design,  test  and  maintain  this  software,  software 
development/support  environments  will  be  extensively  used.  The  significance  of  this  transition  to 
software  is  manifested  in  the  fact  that  50  percent  or  more  of  the  cost  of  acquiring  and  maintaining 
advanced  weapons  systems  is  directly  related  to  software  considerations.  It  is  also  significant  that 
this  dependence  on  software  provides  an  unprecedented  flexibility  to  quickly  adapt  avionics 
systems  to  changing  threat  and  mission  requirements.  Because  of  the  crucial  importance  of 
software  to  military  weapons  systems,  all  NATO  countries  are  devoting  more  research  and 
development  funds  to  explore  every  aspect  of  software  science  and  practice. 

The  purpose  of  this  Symposium  was  to  bring  together  military  aerospace  software  experts  from  all 
NATO  countries  to  share  the  results  of  their  software  research  and  development  and  virtuaUy 
every  aspect  of  software  was  considered  with  the  following  representing  a  partial  set  of  topics: 
Aerospace  Electronics  Software  Specification,  Software  Design,  Programming  Practices  and 
Techniques,  Software  Validation  and  Testing,  Software  Management  and  Software  Environments. 
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Development,  NATO  Software  Development,  NATO  Software 
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acquiring  and  maintaining  advanced  weapons  systems  is  directly  related  to  software  acquiring  and  maintaining  advanced  weapons  systems  is  direcdy  related  to  software 
considerations.  It  is  also  significant  that  this  dependence  on  software  provides  an  considerations.  It  is  also  significant  that  this  dependence  on  srrftware  provides  an 
unprecedented  flexibility  to  quickly  adapt  avionics  systems  to  changing  threat  and  mission  unprecedented  flexibility  to  quickly  adapt  avionics  systems  to  changing  threat  and  mission 
requirements.  Because  of  the  crucial  importance  of  software  to  military  weapons  systems,  requirements.  Because  of  the  crucial  importance  of  software  to  military  weapons  systems. 
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